Next year's software budget is not one number for one project. It is four lines that behave differently: building new things, keeping existing things running, licences and infrastructure, and the reserve for what breaks. Most budgets that fail in June failed because the second and fourth lines were left out in October.
This guide is for the person who has to submit a figure to a board or a finance team and then defend it, without a technical background to fall back on.
Key takeaways
- Split the budget into four lines, not one: new work, maintenance, recurring costs, and a reserve.
- Maintenance is a percentage of what you already own, not an optional extra, and it grows as the estate grows.
- Recurring costs rise on their own: licences, cloud usage and per-seat tools increase with headcount and traffic without anyone deciding anything.
- A budget with no reserve is a budget that will be reopened, usually at the worst moment of the year.
The four lines
New work. The projects you intend to start or finish. This is the line everyone focuses on, and it is usually the only one presented.
Maintenance and support. Keeping what you already run: fixes, updates, security patches, small changes requested by the business, and the support arrangement with whoever built it. This is not optional spending, it is the cost of having the thing at all.
Licences, infrastructure and services. Cloud hosting, databases, monitoring, per-seat tools, payment and messaging providers, domains and certificates. Most of these scale with usage or headcount.
Reserve. The line for the incident, the urgent integration, the supplier that raises prices, the regulation that changes. If it is not in the budget, the first unplanned event becomes a request for more money, which is a much harder conversation than a line item agreed in advance.
Work out what you already own before adding anything
Before deciding what to build, list the systems you currently run, who maintains each, what each costs annually, and what would happen if it stopped. Most organisations find at least one system nobody has a named owner for, and at least one recurring cost nobody can explain.
That list is the most useful page in the whole exercise. It converts the budget conversation from a wish list into an inventory with numbers attached.
Decide the ratio between running and building
The practical question a board will ask is how much of the budget goes to new capability and how much to keeping the lights on. There is no correct ratio, but there is a correct way to answer it.
If almost everything goes to maintenance, that is a signal about the state of the existing estate, and the conversation should be about modernisation rather than about the budget. If almost nothing does, the maintenance is either being absorbed invisibly by internal staff or it is not happening, and both of those become visible within a year.
Present it as consequences, not as costs
A board does not evaluate software spending on merit, it compares it against everything else. So each line needs a consequence attached.
- What does this project make possible, in operational terms rather than technical ones?
- What happens if the maintenance line is cut by half? Name the specific risk, not a general one.
- Which recurring cost is tied to growth, so that the number rises if the business succeeds?
- What is the reserve for, with an example from the last two years?
Get the timing right
Budget approval usually runs from October to December, which means the decisions about what to build next year are made before the current year has finished. Two habits make that easier.
First, keep a running list of requests through the year, with dates, so the October conversation is based on a record rather than on whoever asked most recently. Second, do a short review in September of what was budgeted this year against what was actually spent, because that difference is the best available estimate for next year.
Related guides
- The measurement side of it is covered in the total cost of custom software.
- A related mistake worth avoiding is described in how to prioritise digital projects.
- If maintenance is consuming the roadmap, measuring maintenance load against roadmap is the next step.
If building next year's plan surfaces work that needs scoping before the budget is submitted, Discuss Your Plan.
Ali Boran Gazel