There are two kinds of software firms: the ones that have carried a pager for their own product, and the ones that hand off at launch and find out what happened later. We've been both. Running our own SaaS alongside client work is the single most useful thing we've done for the client work — not because it's a badge, but because operating a product teaches you a category of things that building one simply doesn't.
Agencies advise. Operators know. The gap between those two shows up in exactly the places a proposal never mentions.
Dogfooding is a credibility strategy
When we tell a client that a subscription flow needs a dunning strategy before launch, that isn't a line item we invented to pad the estimate. It's a scar. We can pull up the exact failure — the customer whose card expired, whose retries silently exhausted, who churned without ever seeing an email — because it happened to us, on our own revenue.
That changes sales conversations in a way that's hard to overstate. "Best practice says" is an argument. "Here's what this cost us in month three" is evidence. Prospects can tell the difference immediately, and so can we when we're on the other side of the table hiring subcontractors. The first question we ask any vendor now: what do you operate? Not what have you built — what do you run, today, with your own name on the uptime?
Billing is where the edge cases live
Nothing in our engineering education prepared us for how much of a subscription product is billing, and how little of billing is the happy path. Charge a card, provision an account — that's an afternoon. Then reality arrives:
- The card that expires between trial and first charge.
- The upgrade mid-cycle that needs proration, and the downgrade that needs it in reverse — with a customer reading the invoice line by line.
- The webhook that arrives twice, or late, or never, and the subscription state that quietly diverges from the payment processor's view of it.
- The chargeback filed by someone who forgot they subscribed, which costs a dispute fee on top of the refund either way.
- Sales tax thresholds that turn "we charge $29/month" into a jurisdictional research project once revenue crosses lines you weren't watching.
The deep lesson isn't any single edge case. It's that billing state is a distributed system — your database, the processor, and the customer's bank each hold an opinion, and they will disagree. The processor's webhook stream has to be treated as the source of truth, handlers have to be idempotent, and reconciliation has to be a scheduled job rather than a panicked quarterly cleanup.
We learned that by getting it wrong on our own product, where the cost of the lesson was ours to absorb. Now every client scope with recurring revenue includes dunning, proration, webhook idempotency, and reconciliation as first-class work — priced, scheduled, and explained. Clients occasionally ask why our billing estimate is bigger than a competitor's. It's because ours includes the part that happens after the demo.
Email deliverability is a part-time job
Every SaaS is also, whether it admits it or not, an email company. Receipts, password resets, trial reminders, dunning notices — the product doesn't work if the mail doesn't land, and whether mail lands has almost nothing to do with your application code.
Running our own product forced us through the whole curriculum: SPF, DKIM, and DMARC configured correctly rather than approximately; separating transactional mail from marketing mail so a newsletter's reputation can't drag down password resets; warming a sending domain gradually instead of blasting from a cold one; watching bounce and complaint rates the way you watch error rates, because mailbox providers certainly are. When the major providers tightened bulk-sender requirements — mandatory DMARC, one-click unsubscribe, complaint-rate ceilings — that was a Tuesday for us instead of an outage, because we were already living under stricter self-imposed rules.
None of this is glamorous, and all of it is invisible in a proposal — right up until a client's customers stop receiving receipts and it becomes the only thing anyone wants to talk about. It's in our launch checklist now, as standard as SSL.
The pager teaches what the spec can't
Being on call for your own product is a compressed education in humility. A few things the pager taught us that no requirements document ever did:
The riskiest hour is right after a deploy, so deploys happen when someone is awake and watching, and rollback is a button, not a procedure. Observability is a launch feature — the difference between a five-minute incident and a two-hour one is usually whether the right dashboard existed before the incident started. Most outages are boring: an expired certificate, a full disk, a third-party API changing behavior without a version bump. And the status page you write at 2 a.m. is the moment customers decide whether they trust you — honesty with a timeline beats corporate vagueness every single time.
The pager also recalibrated our sense of what "done" means. A feature isn't done when it works; it's done when it fails visibly, recovers gracefully, and can be operated at 2 a.m. by someone who didn't write it.
How this changed the way we scope
All of this flows directly into how we structure client engagements now.
We scope the ops, not just the build. Monitoring, alerting, runbooks, backup restores (tested, not assumed), and a deploy pipeline with rollback are in the estimate from day one. If a client wants to cut them, that's their call — but it happens as an explicit decision, not an omission they discover during their first incident.
We plan the first ninety days after launch. Launch is the beginning of the product's life, not the end of the project. Our engagements include a post-launch period where the people who built the system are the ones watching it, tuning alerts and fixing the assumptions reality disproves — because that's when the real requirements show up.
We say no with specifics. When a founder wants to skip dunning or ship without observability to hit a date, we can describe — from experience, with numbers of our own — what that decision costs. Sometimes they proceed anyway, eyes open. That's fine. Our job is to make sure nobody is surprised.
Running a SaaS made us slower to promise and more precise about what we promise. Every client, whether they know it or not, is getting the benefit of the tuition we already paid.