Technology budget planning season always produces the same document: a wishlist of new features and initiatives, presented to leadership as if it were the whole picture. It isn't. Every technology budget I've reviewed for a client, from a retail chain in Tangerang to multifinance operations, underfunds two categories that never make it onto the exciting slide: keeping existing systems running, and fixing the debt from last year's rushed decisions. Both bite eventually, usually mid-year, usually as an emergency.
The fix isn't more spreadsheet sophistication. It's a simple three-bucket structure, ordered by priority, that forces honesty about where the money actually needs to go before anyone gets to talk about what's new and exciting.
I use this with every client during planning season because it surfaces the same uncomfortable truth every time: most technology budgets fail not because they picked the wrong new initiative, but because they starved the boring stuff first.
What is the run, fix, grow framework?
The run, fix, grow framework splits a technology budget into three ordered buckets, funded top to bottom rather than bottom to top: keep systems running, pay down technical debt, then fund new initiatives. Order matters here, funding sequence, not the percentages, is what keeps a budget honest.
Run (keep the lights on). Hosting, licenses, existing SaaS subscriptions, security patching, backups, the maintenance contract on your ERP or POS system. This is non-negotiable spend that keeps what already works, working. For most SMEs I work with, this lands between 40-55% of the total technology budget, and it's almost always higher than leadership initially expects.
Fix (pay down technical debt). The workaround that's been "temporary" for eight months. The integration held together by a scheduled script someone forgot they wrote. The legacy system nobody wants to touch because documentation doesn't exist. This bucket doesn't produce a demo-able feature, which is exactly why it gets cut first and why cutting it is the most common budgeting mistake I see.
Grow (new initiatives). New features, new products, new automation, the things that make it onto the roadmap slide. This is genuinely the smallest bucket in a realistic budget, often 20-30%, and that's fine. Grow spend compounds much better when Run and Fix aren't quietly failing underneath it.
Why do most technology budgets get this backwards?
Most technology budgets get this backwards because the natural instinct, especially when money gets tight, is to protect Grow first since it's visible to leadership and customers, while quietly trimming Run and Fix because nobody notices maintenance until it breaks. I've watched this play out with a retail chain that deferred point-of-sale system maintenance for two budget cycles to fund a new mobile app. The app shipped. Three months later a POS outage during a holiday sales weekend cost more in lost transactions than the entire deferred maintenance budget would have.
Technology budget planning done honestly treats Run as the floor, not the leftover. If Run and Fix together would consume the whole budget, that's real information: it means last year's initiatives were underfunded on maintenance, and next year's plan needs to either secure more budget or explicitly reduce scope, not just hope the debt stays quiet another year.
How much should a technology budget hold back for what will break?
A technology budget should hold back roughly 15% of the total for what will break, since something always breaks that wasn't in the plan. A vendor deprecates an API. A regulation changes and forces a system update outside your control. A key integration partner changes their pricing model. I build this contingency line into every plan I write for clients, held separately and not pre-assigned to any bucket.
This isn't pessimism, it's pattern recognition. Across every planning cycle I've run, something in this range gets consumed by unplanned work. Budgets without this line don't avoid the unplanned cost, they just fund it later by cannibalizing Grow initiatives mid-year, which is how a promising roadmap quietly turns into nothing shipping.
A sample allocation for a mid-sized SME
| Bucket | Share | Example spend |
|---|---|---|
| Run | 45% | Hosting, licenses, patching, backups, support contracts |
| Fix | 25% | Retiring one legacy integration, paying down a known workaround |
| Grow | 15% | One or two new features or automation initiatives |
| Contingency | 15% | Unplanned vendor changes, regulatory shifts, emergency fixes |
Adjust the ratios to your context, a business mid-migration off a legacy system will run Fix higher, a business post-migration can push more into Grow. But the ordering discipline, Run first, Fix second, Grow last, holds regardless of the exact percentages.
Turning this into a planning conversation, not a spreadsheet exercise
The most useful thing I do with clients during budget season isn't building the spreadsheet, it's asking three questions before any numbers go in:
- What's currently running that we'd be in real trouble without, and is it actually funded to stay stable next year?
- What technical debt have we been quietly carrying, and what does it cost to retire versus what it costs to keep paying interest on?
- Of the new initiatives on the table, which ones have a named business owner and a real deadline, versus which ones are just interesting?
This connects directly to writing a one page digital strategy first, because a budget without a strategy behind it just becomes a negotiation over whose pet project gets funded.
The practical takeaway
Fund Run first, Fix second, Grow third, and hold 15% back for what you can't yet see coming. If your budget process starts with the new initiatives list and works backwards to what's left for maintenance, you're planning for a good year and hoping nothing breaks. Plan for the ordinary year instead: things degrade, vendors change terms, and the boring infrastructure work is what makes next year's exciting initiatives possible at all.
