What it really takes to keep software running after launch

Most conversations about commissioning software end at the launch date, as if the story finishes when the product goes live. In reality, launch is when the software starts existing in the world — and the world keeps changing around it. Browsers update, phone operating systems update, the services your app connects to change their rules, security researchers find new classes of problems, and your own business changes what it needs.

None of this means software is fragile or that maintenance is a scam. It means software is more like a vehicle than a sculpture: it works for years, but only if someone checks the oil. This guide explains what that checking actually involves for a small business system, what it costs, and how to avoid the two classic failure modes — paying for maintenance that never happens, and paying nothing until something breaks expensively.

The word "maintenance" hides four different activities with different urgency and cost profiles. Separating them makes every conversation with a developer or agency clearer, because you can ask which of the four a support agreement actually covers.

Unmaintained software rarely fails on day one. It decays in a specific sequence. First, small annoyances appear — an integration hiccups, a page loads slower, an email lands in spam. Then a dependency somewhere announces its end of life, and the cost of every future change quietly doubles because updates must happen before anything else can. Finally something visible breaks — payments, logins, the booking form — and the fix is urgent, expensive, and performed under pressure by whoever is available rather than whoever is best.

The pattern to notice: the total cost of neglect is almost always higher than the cost of steady upkeep, but it arrives later and all at once, which makes it easy to choose by accident. Businesses that budget a small ongoing amount — and actually spend it — almost never experience the emergency version of this story.

A widely used planning figure for software upkeep is 15–25% of the original build cost per year, covering updates, fixes, and small improvements. A simple internal tool with few integrations sits at the low end or below it; a customer-facing system with payments, messaging, and third-party connections sits higher because more of the outside world can change underneath it.

Structure matters as much as the amount. For most small systems, the practical options are: a modest monthly retainer that includes updates and a few hours of changes; a pay-as-you-go arrangement with an agreed response time; or scheduled check-ups — a half-day every quarter where someone updates dependencies, reviews errors, and flags risks. The wrong option is the default one: nobody responsible, nothing scheduled, and a plan that amounts to hoping.

The cheapest time to arrange after-launch care is while the builder still knows the project intimately. A handful of questions, answered in writing before the final invoice, prevent most of the painful scenarios.

Maintenance sounds like pure cost, but the improvement category is where small systems quietly compound. The businesses that get the most from custom software are rarely the ones that built the most ambitious first version — they are the ones that made twenty small, cheap changes over two years, each one guided by real use. A field removed here, a reminder reworded there, one report automated: individually trivial, together transformative.

Treat the months after launch as part of the project. Keep a running list of frictions the team notices, batch them into small change requests, and spend the improvement budget on what the list proves matters. That habit — not the size of the original build — is what separates software that gets adopted from software that gets abandoned.