Software Maintenance: What Happens After Launch (and Why It's Not Optional)

Launch day feels like a finish line. The software is live, it works, the first users are on it. It's natural to think the hard part is done.

In reality it's the start of another phase. Software doesn't wear out like a machine, but it ages all the same — and for reasons that have nothing to do with the software itself. This article explains what maintenance really includes, how much it weighs on the budget, and when you can do without it, at least in part.

Nothing changes in your app. Everything around it does.

Apple and Google release new versions of their operating systems every year and update the rules for staying on their stores: Google Play, for example, requires apps to target recent Android versions to remain available to new users. Browsers evolve. The language and framework the software is built on have a lifecycle, and at some point old versions stop receiving security updates. External services — payments, maps, email — change their interfaces and retire the old ones.

Each of these things, on its own, is small. Put together, they're the reason software left untouched for two or three years becomes fragile.

“Maintenance” is a word that bundles different things together. Telling them apart is the first step to understanding what you're paying for.

The last row is the one that causes the most misunderstandings. New features aren't maintenance: they're development. A good contract keeps them separate, so you always know whether you're paying to keep what you have or to get something more.

A figure often quoted in the industry is 15–20% of the initial development cost, every year. It's a rough estimate, useful to avoid being caught off guard, but the real figure depends mainly on three factors.

How many platforms. A web management system has one environment to maintain. An iOS and Android app plus a web panel has three, each with its own updates.

How many integrations. Every connected external service is one more dependency that can change.

How critical it is. If an hour of downtime stops sales, you need monitoring and someone on call. If it's an internal tool used by three people, far less.

The model matters too. A fixed monthly fee gives predictability and ensures someone keeps an eye on the software regularly. A bundle of hours to use when needed is more flexible. Pay-as-you-go costs less on paper, but it usually arrives when the problem has already become urgent.

For a while, nothing. And that's exactly the problem: the saving is immediate and visible, the cost is deferred and invisible.

Then comes an update that breaks a feature, a warning from the store, a vulnerability discovered in a library your software uses. At that point it's no longer about doing one update, but catching up on three years of them at once — with the risk that the versions are so far apart that parts need rewriting. It's called technical debt, and like any debt it accrues interest.

Not all software needs the same level of attention, and it would be wrong to pay as if it did.

A stable internal tool, used by a few people and without payments or particularly sensitive data, can live well on light maintenance: periodic security updates, verified backups and a check whenever a major framework version comes out. Everything else is assessed as needed.

The right question isn't “how much does maintenance cost?” but “how much would it cost me if this software stopped tomorrow?”. The answer tells you how much to invest.