What maintaining an application actually means after launch

There is a natural expectation: the application is finished, it works, so that is that. With buildings, roughly true. With software, not — and the reason is not that it was badly built.

Software does not break on its own. It breaks because everything around it changes.

What changes, even if you change nothing

• Browsers. They update every few weeks. What worked may stop working.
• Phone operating systems. A new version of Android or iOS can disable an application that was not adapted.
• The components the application is built from. Every modern application uses libraries written by others. Those receive security fixes, and old versions stay exposed.
• Legislation. VAT rates, invoicing formats, reporting requirements — they change and they ask nobody.
• The services it talks to. The bank, the courier, the payment provider change their interfaces and announce a deadline.

What maintenance actually covers

Security updates

The invisible part, and the most important. Vulnerabilities in components become public once discovered — including to the people looking for them. An application left un-updated for two years is an open door, however well it was originally written.

Fixing problems that show up in use

No amount of testing covers everything real people do. The first months surface situations nobody thought of. That is normal, and useful.

Monitoring

Somebody has to know the application is running before a customer finds out. The difference between “we noticed and fixed it” and “a customer called us” is everything.

Small adjustments

One extra field, a new report, another export column. Each looks insignificant, but together they are what keeps the application matched to how you work now, rather than how you worked at launch.

What maintenance is NOT

This distinction prevents most misunderstandings:

• A new module that was not in the original scope.
• Redoing the interface because the visual identity changed.
• Integrating with a new system that appeared after launch.
• Scaling up for several times the original volume.

All of these are legitimate. They are development, not maintenance, and it is healthier to treat them that way from the start.

What happens when it is skipped

The application works. For a year, maybe two. Then a small problem appears, and fixing it requires updating components that have fallen far behind. Updating those requires changes elsewhere. What would have been a few hours becomes a project.

That is the mechanism by which perfectly good applications end up rewritten from scratch: not because they were badly made, but because they were left behind long enough to stop being worth recovering.

What to ask for in any contract

1. How fast somebody responds to a problem that stops work, and how fast to a minor one.
2. What is included and what is charged separately, written explicitly.
3. Who owns the code and where it is kept. If the answer is vague, that is a real risk.
4. What happens if you want to work with somebody else. A confident supplier does not dodge that question.

The last one is the most important and the least often asked.

← Back to the blog