Planning a technology budget that survives the year
Most technology budgets are built for launch and then surprised by year two. The fix is less about forecasting accuracy and more about naming the categories before the money is committed.
Four lines, not one
Split the number into build, hosting and licences, maintenance, and improvement. Build is one-off. Hosting and licences recur monthly. Maintenance is the work that keeps the system correct and secure. Improvement is the work that makes it better.
When these sit in one pot, maintenance silently loses to new features until something breaks, and then the repair costs more than the maintenance would have.
A workable ratio
For a custom platform, plan roughly 15 to 20 percent of the original build cost per year for maintenance, and a separate amount for improvement that reflects your growth plans rather than the codebase.
For a website, the equivalent is smaller but real: platform updates, security patches, content support and performance checks.
Write down what you will not do
A budget that lists only inclusions is a wish list. Listing the features you are deferring, and the trigger that would bring them back, keeps the conversation honest when a stakeholder asks why something is missing.
Common questions
- What percentage of build cost should maintenance be?
- Fifteen to twenty percent a year is a reasonable planning assumption for custom software. Systems with heavy integration or compliance requirements often sit at the higher end.
- Should maintenance be a retainer or ad hoc?
- A retainer buys predictable response and continuous small fixes. Ad hoc suits stable systems with low change volume, but it makes urgent work compete for calendar space.
Next step
If this question is live in your business right now, describe the situation and you will get a written view on the options, including whether you should build at all.
Discuss your projectRelated notes
All insightsCustom software or off-the-shelf: how to decide
A practical framework for choosing between configuring an existing product and commissioning custom software, based on where your process actually differs.
ReadStrategyHow to write a technical brief that gets accurate quotes
The brief structure that separates a project that can be estimated from one that cannot, with the eight sections worth writing before you talk to any developer.
ReadStrategyRebuild or repair: an honest test for an ageing website
How to tell whether your existing website needs a migration or a targeted fix, using five checks that take an afternoon rather than a month.
Read