Build an IT Budget That Handles Surprises Without Hurting Core Operations

I build technology budgets as a founder rather than as a CIO, so mine is smaller and less forgiving. There is no other department to raid.

The structure is three buckets: run, which keeps the lights on; change, which is the work we chose to do; and reserve, which is deliberately unallocated, around 15% of the total. The reserve exists so that surprise work does not get paid for by cancelling something that was already the right decision, which is what happens when there is no slack in the plan, and it is exactly how core operations get starved.

The rule attached to change spending is that anything new names what it replaces. Not a vague promise to review the stack later. The tool it retires, and the date. Without that, software spend only travels in one direction, because every individual purchase is defensible and nobody is looking at the total.

What saved us was an end-of-life notice on a platform we depended on, arriving midyear with a migration attached that nobody had planned or wanted. The reserve absorbed it. Nothing agreed had to be killed, and I did not have to reopen a negotiation with anyone.

Build the surprise in. You cannot forecast which one arrives, but the arrival of one is the most predictable thing in the plan.

As the founder of HesapCebimde, one rule I rely on is treating the IT budget as a maintained financial product rather than a static number. That means publishing the underlying assumptions, the calculation formula, the update date, and any hidden costs so changes are visible. With those items kept current, it is clear which lines are core and which are discretionary, so midyear shifts can be covered by reassigning discretionary spend instead of cutting essential operations. This approach keeps core services funded while allowing the flexibility to absorb surprise work.

I decided the budget the way I ran the product: route what other teams already do better, and build what no one else will build for you.

We run a three-person team. Our infrastructure spend goes almost entirely to partners who already solved specific problems at scale. Perpetuals route through Hyperliquid via builder codes. Prediction markets route through Polymarket. We pay for what works and skip the part where we rebuild matching engines or oracle stacks from scratch. That keeps fixed costs low and predictable, which is the only thing that matters when the team is three people and the roadmap changes every six weeks.

The mechanism that saved us midyear was treating infrastructure partnerships as variable cost, not capital expenditure. When user demand shifted from prediction markets to perpetuals in Q3, we scaled routing through Hyperliquid without rewriting the architecture or burning a quarter's budget on new hires. The system flexed because the underlying infrastructure was already built by someone else. We just routed more traffic.

The reserve that actually worked was time, not money. We kept one full week per month unscheduled. No feature work. No integrations. Just room to respond when something broke or when a user surfaced a priority we had not planned for. That buffer let us ship fixes in days instead of pushing them to the next quarter, which is what happens when the calendar is full and the decision-making layer is separate from the execution layer.

The trade-off is that routing costs more per transaction than building in-house over a long enough time horizon. But the three of us can ship five product lines because we are not maintaining the infrastructure underneath. The budget works because we are not trying to be vertically integrated. We are trying to ship faster than teams ten times our size, and the only way that happens is by not building what we do not need to own.

I wouldn't try to predict every IT expense perfectly at the beginning of the year. Software changes, business needs change, and sometimes a requirement comes up that you simply could not have planned for twelve months earlier.

What I would do is separate the things the business genuinely depends on from the things we would like to do.

The first group is fairly straightforward: software licences, security, maintenance, and other systems that people need to do their jobs. I would budget those first and make sure they are protected. New projects or upgrades would sit separately, with some room left for unexpected requirements during the year.

I also think the approval process matters just as much as the amount you put aside. If something new comes up halfway through the year, someone should be asking: Do we actually need this now? What happens if we wait? And is this replacing something we already pay for?

At CYLL, we build some of our custom software by working closely with our vendors, so we understand how easy it is to become interested in a new tool or a better way of doing something. However, not every improvement needs to be implemented immediately, because the cost of developing and maintaining a new tool can sometimes outweigh the benefits. If our existing methods are robust, there are workarounds that can achieve the desired results effectively.

For me, the useful discipline is making sure a surprise project does not automatically become a surprise expense. You should still have to decide whether it is important enough to change the plan.