Maintenance is a feature, not an afterthought

Most conversations about a new website or app focus on the launch — the design, the features, the day it goes live. Almost none focus on the years after. Yet that is where the cost, the risk, and most of the value actually sit. A launch is a single moment. The software has to keep working through every day that follows.

We have run sites and apps continuously for over a decade. That experience has taught us something that is easy to say and hard to sell: maintenance is not a chore you tack on at the end. It is a feature in its own right, and it is often the most valuable one you can pay for.

Why software decays if you leave it alone

Nothing about your code changes when you stop touching it — but everything around it does. Browsers ship new versions. The language runtime you built on reaches end of life. A dependency you relied on gets a security advisory. Payment providers change their APIs. Search engines change what they reward. An app that was perfectly healthy at launch slowly drifts out of step with the world it lives in, and the gap only widens.

This is why a site left untouched for three years rarely “just keeps working.” It keeps working right up until the morning it does not — usually at the worst possible time, and usually because of something entirely outside the original build.

What good maintenance actually involves

Maintenance is not staring at a working site and billing for it. Done properly, it is a steady stream of small, mostly invisible work:

• Security updates applied promptly, before a known vulnerability becomes an incident.
• Dependency and runtime upgrades so the foundation stays current rather than rotting quietly underneath.
• Monitoring and backups that catch problems before users do, and make recovery a non-event when something does break.
• Small evolutions as the organisation’s needs shift — a new section, a redesign of a tired page, an integration with a tool the team has started using.

The point of all of it is that nobody ever has to think about whether the software still works. It just does.

The hidden economics

Rebuilds are expensive, disruptive, and risky. Every “let’s just start again” project throws away years of accumulated decisions, edge cases, and institutional knowledge — and then spends months rediscovering them the hard way. A great deal of that expense is avoidable. Software that is maintained continuously rarely needs a from-scratch rebuild, because it never falls far enough behind to justify one.

The economics are unglamorous but clear: a modest, predictable maintenance budget almost always costs less over five years than one neglected build followed by an emergency rebuild. You are paying to never have the emergency.

Maintenance as a relationship

There is a human side to this too. When the same team has looked after a system for years, they carry context no documentation captures — why a decision was made, which corner is fragile, what a particular client actually needs. That context is what lets a small change stay small instead of becoming a week of archaeology.

One of our longest-running projects is Bakhshish Dham, a charitable organisation whose website, live streaming, and app we have maintained since 2014. The website did not survive a decade of platform change because it was built well once. It survived because it has been cared for, continuously, ever since. The build was the start of the relationship — not the end of it.

If you are commissioning new software, ask not only “what will it cost to build?” but “what will it cost to keep alive, and who will do it?” The answer to the second question matters far more than most people realise on launch day.