What Happens After Launch — The Part Most Quotes Ignore

Most software conversations focus almost entirely on the build. What will it do, what will it cost, when will it be ready. Then it launches, the project closes, and a year later the business is frustrated that the thing is buggy, out of date, and nobody seems responsible for it.

Launch is not the finish line. It's the point at which software starts earning its keep — and starts needing attention. Getting clear about this before you sign is one of the highest-value conversations you can have with any development partner.

Four different things people call "support"

These get bundled together in proposals, which is how expectations diverge. Separate them.

Keeping it running. Hosting, uptime, backups, certificate renewals, security patches, dependency updates. Not optional. Software decays if left alone — operating systems change, libraries get security advisories, certificates expire, third-party APIs deprecate endpoints.

Fixing what's broken. Bugs that surface in real use. Some will exist at launch no matter how well you test, because real users do things test plans don't anticipate.

Helping people use it. Questions, training, occasional hand-holding. Often the most visible form of support, and frequently handled by the client rather than the developer.

Making it better. New features, refinements, responses to what you learn once people are actually using it. This is usually the most valuable category and the one most likely to be omitted from a support agreement.

A proposal that says "12 months support included" without distinguishing these is ambiguous by accident or by design. Ask which of the four it covers.

What it should cost

Industry norms, which are also roughly what we'd expect to charge:

• Hosting and infrastructure: from around $30/month for a modest site through to several hundred for an application with a real database and background processing.
• Maintenance and security updates: budget 15–20% of the original build cost annually. For a $100k build, that's $15k–$20k a year. This sounds like a lot until you price an emergency rebuild.
• Ongoing improvement: whatever you choose to invest. Often a retainer covering a set number of days a month.

The maintenance figure is the one that surprises people, and it's the one worth internalising. It isn't a vendor upsell — it's the cost of the software continuing to work. Skipping it doesn't save money; it defers a larger cost and adds risk in the meantime.

The warranty question

Get this one explicit and in writing: what counts as a bug versus a change, for how long, and at whose cost?

A reasonable arrangement is something like: defects — where the software doesn't do what was agreed — are fixed free for a defined period, commonly 30 to 90 days after launch. Changes — where you've decided you want something different — are quoted separately.

The grey area between those two is where relationships sour, so agree the principle before you need it. A partner who'll discuss this openly up front is telling you something useful about how they operate.

Automate the watching

Here's the shift that separates software that ages well from software that quietly rots: you should find out about problems from your monitoring, not from your customers.

The baseline worth having on anything that matters to your business:

• Uptime monitoring that checks the site or app every few minutes from outside your infrastructure and alerts a human when it fails.
• Error tracking that captures exceptions in production with enough context to diagnose them, grouped so a recurring problem is one alert rather than four thousand.
• Performance monitoring so you notice the gradual slowdown before it becomes a complaint. Response times drift as data volumes grow.
• Automated backups with tested restores. A backup you have never restored is a hypothesis, not a backup. Test it on a schedule.
• Certificate and domain expiry alerts. An embarrassing, entirely preventable category of outage.
• Automated dependency and security updates, raising a pull request when a library publishes a patch. This turns a once-a-year security scramble into routine, low-risk maintenance.
• Cost alerts, particularly for anything using metered services. A runaway process should page someone, not appear on a bill.

None of this is expensive to set up — often a day or two of work and modest monthly fees. The return is that your first indication of trouble is an alert rather than an angry email.

The difference between a well-maintained system and a neglected one is rarely effort. It's whether anyone is being told when something goes wrong.

Use what you learn

The most valuable thing about the post-launch period is information. Before launch, every decision about what users want is a guess. After launch, you can watch.

Worth instrumenting from day one:

• Which features get used, and which don't. The gap between what you expected and what happens is where your roadmap lives.
• Where people drop out of key flows.
• What support questions cluster. Repeated questions are usually a design problem, not a training problem — and often a good candidate for automation or an AI assistant once the pattern is clear.
• What people ask for. Not as a feature queue to implement literally, but as evidence of the underlying problem.

Plan a genuine review at 30, 60 and 90 days. Look at the data, talk to real users, and decide what to change. The teams that get outsized value from software are the ones that treat launch as the beginning of the learning, not the end of the spend.

Who owns what

Before the project closes, confirm you hold:

• The source code, in a repository you own — not the developer's account.
• Hosting and domain accounts in your name, with your billing.
• All third-party service accounts — payments, email, analytics, model providers — under your control.
• Credentials, stored somewhere secure that survives a staff change.
• Deployment documentation sufficient for a competent developer who has never seen the system to build and release it.

This matters most in the scenario nobody plans for: your relationship with the developer ends. If everything above is in your possession, that's an inconvenience. If it isn't, it's a crisis, and it's a surprisingly common one. Our guide to choosing a development partner goes further into what to establish before you start.

Questions to settle before you sign

• What exactly does support include, and what's billed separately?
• What's the response time for something that's completely down, versus a minor bug?
• Who monitors it, and what are we alerted about?
• What's the warranty period, and how is a bug distinguished from a change?
• Who holds the accounts and the code?
• What does it cost to leave, and what would a handover look like?

A partner who answers these clearly and without defensiveness is a partner planning to be around. That's most of what you want to know.

---

Inherited a system nobody's maintaining, or coming to the end of a build and wondering what happens next? Get in touch — we take on support for software we didn't build, and we'd rather set it up properly than be called when it's already down.