Most conversations about custom software end at the build price. Finance approves a project, the system goes live, and the budget line closes. Then, in year two, the questions start: who pays for the hosting, who fixes the bug that appeared after a vendor changed an interface, and who adds the report the sales team asked for?
Our article on the real cost of custom software covers what it takes to build. This one covers the time after launch, and gives CFOs and technology leaders a frame for budgeting years two to five.
Why the build price is not the full price
Software is closer to a piece of equipment in use than to a finished building. The business around it changes, the platforms underneath it receive updates, and users find new needs. A system that is not looked after slowly stops matching the way you work. We describe the early symptoms in five signs you have outgrown your software.
We do not quote a standard percentage of the build price here. Published rules of thumb differ widely, and the right figure depends on how the system was built, how many people use it and how fast your business changes. A better approach is to split the cost into three lines and estimate each one from your own data.
Line one: running
This is the cost of keeping the system available and safe, whether or not anyone asks for anything new.
- Hosting, storage and backups
- Licences and third-party services the system depends on
- Monitoring, and someone who responds when an alert fires
- Security updates for the framework, libraries and servers
- Renewals such as certificates and domains
Running costs are the easiest to predict. Most of them appear on invoices you already receive, and they change slowly. Ask the team to list every item with its monthly or yearly price, and to name who owns each one.
Line two: fixing
Every system has defects, and every integration eventually changes under it. Fixing covers the unplanned work that keeps the system doing what it did on launch day.
- Bugs found in real use
- Changes forced by outside parties, such as an updated interface from a supplier or a bank
- Data corrections after something went wrong
This line depends strongly on the quality of the original build. A system with tests, clear documentation and a tidy structure is cheaper to fix than one built in a hurry. Estimate it from the first months after launch: count the fixes, note how long each took and treat the result as a starting level. If the line grows steadily, it is a signal of accumulating debt; our guide to the hidden cost of technical debt explains why.
Line three: extending
This is new capability: a new report, a new integration, a new type of user. Unlike the first two lines, extending is a business choice. You can spend more on it when the opportunity justifies it and less when it does not.
Because it is a choice, it should be planned against the roadmap and approved like any other investment. A useful habit is to reserve a fixed amount of capacity each quarter and let the business decide how to use it, instead of approving every request as a separate project.
What happens if you do not budget for it
The cost does not disappear. It changes form:
- Outages and workarounds. Without running costs covered, nobody watches the system until a customer notices.
- Security exposure. Unpatched components are a known entry point for attackers.
- Slower change. Without a fixing budget, shortcuts pile up and each new feature takes longer. A fixed share of capacity for this is covered in our article on the technical debt budget.
- A large rewrite. The most expensive outcome is a replacement project forced by neglect, which usually costs far more than steady upkeep.
A worked example (invented numbers, for illustration only)
Imagine a company that built an internal order system for a fixed price. In year one, the invoice is the only cost. For year two, the CFO and the technology lead sit down with the last six months of invoices and tickets.
- Running: the hosting and monitoring invoices are known, so this line is simply their yearly total plus a fixed number of hours for security updates.
- Fixing: the team counts the fixes made since launch and takes their average yearly effort as the baseline, adding a margin because the first months often include launch defects.
- Extending: the business lists three wishes. The CFO funds the one with a clear payback and parks the other two for the next quarter.
The three amounts go into one sheet with an owner for each line. At every quarterly review, the team compares the actual spending with the sheet and explains differences in a sentence or two. The numbers here are deliberately not given: use your own, since any figure we printed would be made up.
How to build your own frame
- List what exists. Collect invoices and tickets from the months since launch.
- Sort them into the three lines. Anything that does not fit is a sign the list is incomplete.
- Name an owner for each line. A line without an owner is the one that gets cut first.
- Agree the frame for one year, and set a quarterly review with simple evidence: spending against the sheet, number of fixes and time to release a small change.
- Look for the trend. A growing fixing line or a longer time to change is the cue to talk about debt, not to simply add money.
Common mistakes
- Treating the build price as the whole cost
- Merging all three lines into one, so nobody can see what is growing
- Letting extending requests consume the capacity needed for running and fixing
- Estimating from a general percentage instead of your own invoices
- Never reviewing the frame after the first year
Where to start this week
Ask your technology lead for every invoice and ticket since launch. Sort them into running, fixing and extending, and write the yearly total beside each. A one-page sheet with three lines and three owners is enough to take to the next budget meeting. If you also need to compare options before deciding, our decision memo for the CFO gives a short format.
Sources
- Your own invoices, tickets and release records, used as described; the worked example contains no real figures.
- Our related articles linked above.