What it costs to keep custom software alive
Software you own has a standing cost even when nobody is changing it. Knowing the number is what makes the build decision honest.
Updated September 2026
- Dependencies age whether or not the application changes. Patching is a standing cost, not a project.
- One author and no documentation is the expensive configuration, regardless of code quality.
- Hosting, monitoring and backup are ongoing and often unbudgeted after the project closes.
- Budget a share of the original build cost each year, and treat that as the price of ownership.
Custom software is often compared against a licence fee and found cheaper. The comparison is incomplete, because owning software carries costs that a subscription hides inside its price.
1. Dependencies age
Frameworks, libraries and runtimes reach end of support on their own schedule. Security patches stop. A version you depend on becomes one nobody maintains.
This happens whether or not your application changes. It is the most reliably underestimated cost of ownership, and the one that turns a working application into an urgent project three years after everyone stopped thinking about it.
2. The platform underneath moves
Operating systems, databases, cloud services and identity providers all change. Authentication methods get deprecated. APIs you call get versioned out.
Each is small individually. Collectively they are a steady stream of work that has to be absorbed somewhere.
3. Hosting, monitoring and backup
Ongoing, and frequently unbudgeted because they were inside the project cost originally. Also the things most likely to be quietly neglected: an application with no monitoring fails silently, and a backup nobody has restored from is an assumption rather than a control.
4. Knowledge
The largest hidden cost. An application understood by one person is a risk that grows quietly. When that person leaves, the next change costs several times what it should, because someone has to learn the system before touching it.
Documentation written for someone who was not in the room is what converts this from a risk to a cost. It is also the first thing dropped when a build runs late.
5. Small changes
Business processes change, and the software has to follow. A new field, a changed rule, a report someone needs. Individually trivial, collectively a steady demand that needs somewhere to go.
Without a route for small changes, they accumulate until they become a project — and projects get deferred, so people build workarounds in spreadsheets, which is how you end up with two systems.
6. Integration drift
Every system your application talks to will change. Each of those changes is work for you, on somebody else’s timetable.
What makes it cheap or expensive
The same software can sit at either end of the range depending on four things: whether it is documented, whether more than one person understands it, whether its dependencies are current, and whether it has tests that let a change be made with confidence.
Software with all four is inexpensive to own. Software with none is expensive regardless of how well it was written, because every change starts with an investigation.
How to budget it
A reasonable planning assumption is an annual share of the original build cost, covering the six items above. Set that as a standing line rather than treating each occurrence as an unplanned project.
The point is not to discourage building. Custom software is the right answer whenever the process is genuinely yours and nothing on the market fits. The point is that the comparison should be ownership cost against subscription cost — which is a fair comparison, and often still favours building.
The practice behind it.
Owning something you cannot maintain?
We build in short cycles you can see, and hand over the code, the data and documentation written for someone who was not there.