Annual IT budget planning usually starts with a wish list and ends with a number nobody can defend in March. The better way to build next year's technology budget is to stop guessing and start with what you actually spent this year, then adjust deliberately, line by line, instead of picking a round number and hoping it holds.
I've built this budget for my own consulting practice every year, and I've sat across the table from owners building theirs for the first time. The pattern that works is the same every time: actuals as the floor, maintenance funded before anything new, and a hard cap on experimental spend that isn't tied to a measurable outcome.
Start with actuals, not aspirations
Pull every technology expense from the last 12 months, hosting, software subscriptions, contractor invoices, one-off dev projects, support retainers. Not a rough memory of it, the actual numbers from your accounting system. This is your base. Most owners skip this step because it's tedious, and then wonder every year why the budget never matches reality. It doesn't match reality because it was never built from reality.
Once you have the base, sort it into three buckets:
- Keep-the-lights-on. Hosting, licenses, support contracts, anything that breaks something if you stop paying it.
- Recurring improvement. Ongoing dev work, a maintenance retainer, incremental feature additions to something already live.
- One-off projects. Anything that happened once this year and won't repeat, a migration, a new system build, a one-time integration.
Next year's budget starts as last year's keep-the-lights-on number, adjusted for known changes (a new hire needing a seat, a vendor price increase you've already been notified of), plus whatever recurring improvement work you intend to continue.
Fund maintenance before anything new
The single most common budgeting mistake I see is funding new initiatives first and treating maintenance as whatever's left over. It should be the opposite. If your existing systems aren't funded to stay healthy, security patched, dependencies updated, backups tested, every new project you build on top of them inherits that risk. Subscription creep is one symptom of under-managed recurring spend; unmaintained core systems are the more expensive one, because the bill shows up as an outage instead of a line item.
A rough rule that's held up across the SME clients I work with: budget at least 15 to 20 percent of your total technology spend to maintenance and upkeep before allocating anything to new features or new tools. If your current spend has zero explicit maintenance line, that's not efficiency, that's deferred cost.
Cap experimental spend, and tie it to a decision
Every business should have some budget for trying things, a new AI tool, a pilot integration, a proof of concept. The mistake isn't having this bucket, it's leaving it open-ended. Cap it as a fixed percentage of total budget, I use 10 to 15 percent, and require that every experimental line has a decision date and a success metric attached before you spend a Rupiah.
"We're trying an AI customer service tool for two months, and we'll know it's working if resolution time drops by 20 percent" is fundable. "We're going to explore some AI options this year" is not a line item, it's a wish, and wishes are exactly what turn into January enthusiasm and December confusion about where the money went.
The template
| Category | % of Budget (typical SME) | Rule |
|---|---|---|
| Keep-the-lights-on | 40-50% | Based on actuals, adjusted for known changes |
| Recurring improvement | 20-30% | Tied to a named initiative with an owner |
| Maintenance and upkeep | 15-20% | Non-negotiable floor, funded before new work |
| Experimental / new | 10-15% | Capped, with a decision date and metric per line |
Every line needs an owner, someone accountable for whether it delivered, and an outcome, a business result, not a technical description. "Migrate to new hosting" is a technical description. "Reduce hosting cost by 30 percent and eliminate the outages we had in Q3" is an outcome. Budget the second way and you can actually review performance against the number in twelve months.
Reviewing mid-year, not just at year-end
Set a 90-day check-in on the experimental bucket specifically, that's where drift happens fastest. Keep-the-lights-on rarely surprises you. Experimental spend without a check-in quietly becomes six new subscriptions nobody remembers approving. This is also the moment to fold in whatever's on your AI roadmap for the year, so new initiatives get evaluated against the same budget discipline as everything else, not treated as a separate, unaccountable category because it has "AI" in the name.
The takeaway
Annual IT budget planning done well is boring, and that's the point. Base it on actuals, fund maintenance before anything new, cap experiments with a metric attached, and give every line an owner. The businesses that get surprised by their technology spend are almost always the ones that started from a wish list instead of a ledger.