Software is sold as a project with an end date and lived as an obligation with none.
The build is the visible part and frequently the smaller part. A system that runs an operation for a decade will spend most of that decade being maintained — patched, adjusted as the business changes, kept working as the platforms underneath it move. Whether that decade is manageable or steadily worsening is largely decided during the build, by choices that look like details at the time.
Software does not decay, but its surroundings move
A system left untouched does not break by itself. Everything around it moves, and the gap accumulates.
Dependencies age. Libraries stop being maintained, and the security fixes stop with them.
Platforms change. Operating systems, browsers, runtimes and hosting all move, and eventually something the system assumed is no longer true.
Obligations change. Tax rules, reporting formats, regulatory requirements. These arrive with deadlines and no regard for your roadmap.
The business changes. New locations, new products, a different way of pricing. A system that cannot follow becomes the constraint on the operation it was built to serve.
The last is the one that decides a system's fate. Technical decay is manageable. A system that prevents the business changing gets replaced regardless of how well it runs.
The three things that decide maintainability
Whether anyone understands it
The most common way a system becomes unmaintainable is that the people who understood it left.
This is not primarily about documentation, which ages and is rarely read. It is about whether the system is comprehensible — whether a competent engineer encountering it can work out what it does and why, from the code and its structure.
Systems accrete undocumented rules over years: an exception for one customer, a workaround for a supplier's format, a condition nobody can explain. Each was reasonable. Collectively they become knowledge held by one person, and when that person leaves, every subsequent change becomes an archaeology exercise first.
The practical protection is keeping the number of special cases small, and recording why whenever one is added. The reason matters more than the mechanism — the mechanism is visible in the code, the reason never is.
Whether changes can be made safely
The question that determines cost per change: if I alter this, how do I know I have not broken something else?
Where the answer is "we test it manually and hope", every change carries risk, and risk makes people reluctant. Reluctance means changes are batched into large infrequent releases, which are more dangerous than small frequent ones — the opposite of what caution intends.
Where changes can be verified quickly, they stay small, and small changes are how a system keeps up with a business rather than falling behind and being replaced.
Whether it can be left
Exportability is usually discussed as a commercial protection. It is also a maintenance property.
A system whose data can leave in standard formats can be replaced incrementally — one function at a time, as needs change. One whose data is locked in has to be replaced all at once, which is expensive enough that businesses defer it, which means running an inadequate system for years longer than they should.
Our position is that data stays exportable in standard formats, and the maintenance argument is part of why. It is covered alongside the other requirements in security and data ownership in client systems.
The deferral trap
Maintenance is uniquely easy to postpone, because nothing visibly breaks when you do.
Skipping a dependency update this quarter has no consequence. Skipping it for three years means the eventual update is not an update — it is a migration across several major versions, with breaking changes, done under pressure because a security issue forced it.
The cost curve is not linear. Small regular maintenance is substantially cheaper than the same work accumulated, and the accumulated version arrives at a moment you did not choose.
The practical version for a business: a modest recurring maintenance budget is not overhead. It is what prevents a much larger unplanned expense arriving at the worst time.
What to establish before a system is built
The decisions that matter are made early, and they are commercial as much as technical:
Who maintains it, and at what cost. Get the ongoing figure before signing, not at renewal.
What a change costs, and how long it takes. Rate and lead time, so that adapting the system is a normal activity rather than a negotiation.
What happens if the people who built it leave — on their side and yours.
Whether another firm could take it on. If the answer requires the original team, you have a dependency rather than an asset.
How you get everything out. Immediate, unqualified answer expected.
These are the same questions in how to evaluate a software partner, and they matter more over years than any feature comparison.
What we build to
Truffaire has delivered ten systems on a shared architecture, and the reason we do it that way is partly maintenance: a shared foundation is maintained once rather than ten times, and an engineer who knows one deployment can work on another.
Two positions that follow directly:
Fewer modules, actually used. Every module is a maintenance obligation. Anything not genuinely used is cost with no return, and it is also a place stale data misleads someone.
Continuous adaptation rather than periodic overhaul. An operation changes, and a system that cannot change with it becomes the next legacy tool. Maintenance is a phase of the work, not an add-on — which is the position in what it means to build a system that endures.
Frequently asked questions
What should maintenance cost annually?
It varies with complexity, and the important thing is that it is a known figure agreed before you commit rather than discovered later. A vendor vague about ongoing cost is planning to tell you afterwards.
Can we maintain it ourselves?
If it is comprehensible and you have the capability, yes — and confirm that another firm could also take it on. Self-maintenance that depends on one internal person reproduces the same risk in a different place.
How do we know if our system is becoming unmaintainable?
Three signals: changes take longer than they used to, only one person can make them, and people have started working around the system rather than asking for changes. The third is the clearest.
Is it cheaper to rebuild than maintain?
Occasionally, and less often than it is proposed. Rebuilding discards accumulated business logic — including the undocumented rules that turn out to matter — and reintroduces every migration risk. Rebuild when the architecture genuinely blocks the business.
What about software we bought rather than built?
The same questions apply, with less control. Ask about the vendor's own upgrade path, what happens on change of control, and — again — how you export everything.
Where to start
Ask two questions about your current systems. If the person who knows this best left tomorrow, what would happen? And when was the last time anything underneath it was updated?
If the answers are "we would struggle" and "we are not sure", that is not an emergency today and it is a cost accumulating quietly. Both are cheaper to address now than at the moment something forces them.
If you want a read on where your systems stand, get in touch.