Version one is the cheap version.
That sounds backwards. The build is the big invoice — months of work, the whole budget, the launch post, the confetti emoji. But the build is a known quantity. You scoped it, priced it, and finished it. What comes next has no scope and no finish date, and it's where SaaS products actually live or die.
Ask anyone who's run one. The product that ships on launch day is the dumbest version of that product that will ever exist. Then real users arrive, and they do things nobody designed for.
The part of the sales pitch that's always missing
Every SaaS development company has a launch plan. Almost none lead with a month-two plan. And buyers let them get away with it, because during the sales process everyone is staring at the same shiny thing: the release date.
Here's what month two actually contains. A user who found a bug in the billing flow on a Saturday. A login provider that changed something and broke your sign-up. A database query that was fine with fifty tenants and is not fine with five hundred. An app review, a feature request, a churned customer whose exit survey you should read twice.
None of this is a crisis. All of it needs an owner.
The questions to ask before you sign — not after
Who monitors the product after launch, and how will they know something broke before your users tell them? If the answer involves the word "dashboard," ask who watches it at 2 a.m.
What does the warranty actually cover? Thirty days of bug fixes sounds fine until you learn that "bug" means "deviation from the documented spec" and everything you discovered from real users is a "change request." Get the definition in writing.
How does the next release work? Who decides what goes in, how often does it ship, and what does it cost? A product that shipped once and froze isn't a product. It's a screenshot.
And the question nobody asks: what happens when this engagement ends? Your repository, your cloud accounts, your credentials, your documentation — in your name, from day one. The team confident in its work plans for your independence. The team that isn't plans for your dependence.
What good support actually looks like
It's unglamorous. Someone triages incoming issues by severity instead of by whoever emailed loudest. Incidents get a response time that was agreed before the incident. Releases go out on a cadence, with notes. Once a month someone looks at the error logs and the analytics, because the errors users never report are the ones that show up in the churn column.
If you want to see what that structure looks like from a team that builds and maintains SaaS products for a living, this is what that support looks like in practice.
The point
You'll spend more time operating your product than building it. So when you're choosing who builds it, weight the answer to "what happens after launch?" as heavily as "what will it cost to build?" Launch is one section of seven in this pre-signing checklist — and the other six are the ones that save you before month two.
Most buyers do the opposite. Most buyers pay for it later — usually right around month two, on a Saturday, in the billing flow.
FAQ
Is post-launch support really necessary if the product is well built?
Yes, because well-built doesn't mean finished. Operating systems update, third-party APIs change, dependencies patch vulnerabilities, and real users find edge cases no QA cycle catches. Good engineering reduces the volume of post-launch work; it doesn't eliminate it.
What should post-launch support cost?
It varies with product complexity, but think of it as an ongoing operating line, not a surprise. What matters is that the model — retainer, dedicated team, or per-incident — is defined before launch, with response times for critical issues in writing. Any number agreed calmly in advance beats one negotiated during an outage.
*Can't I just hire an in-house developer after launch instead?
*
You can, and many products eventually should. The trap is the gap: the external team leaves, the hire takes three months, and for that window nobody owns the product. If in-house is the plan, say so before the build starts so documentation and handover are designed for it from day one.
What's the difference between a warranty period and a support plan?
A warranty covers defects in what was delivered — things that don't work as specified. A support plan covers everything else: monitoring, updates, small improvements, incident response. You need both, defined separately, because they fail differently when they're missing.
How do I know if a vendor will actually be good at support before I sign?
Ask who their longest-running client is and what that engagement looks like month to month. A team with products it's maintained for years will describe a routine. A team that only ever builds and leaves will describe the build — because that's all they've ever stayed for.
Top comments (0)