blog single

Planning a technology budget that survives the year

Team reviewing an annual plan and budget

Published on:

December 4, 2025

TAG:

OPERATIONS

BY:

Edgeless Team

Read Time:

6 MIN READ

post detail

Technology budgets often fail in the same way. The year starts with a list of projects, a license renewal appears in March, a security issue consumes April and by October the improvement work has not started. The plan was not wrong about the projects. It was missing the work that keeps the current systems running.

Split the budget into three buckets

Run, change and grow. Run covers the cost of keeping existing systems alive: hosting, licenses, support, security updates and the small fixes that keep work moving. Change covers improvements to what exists: a new page template, an integration, a workflow fix. Grow covers new capability: a product, a market, a channel.

Most budgets underfund run and overfund grow. The result is a year of new projects built on a base that keeps breaking. A useful starting point is to fund run first, then change, then grow, and to make the split visible to everyone who approves spend.

The split does not need to be equal or fixed. A young company may spend more on grow. A mature operation may need a year of change to reduce manual work. What matters is that the choice is deliberate and that run is not treated as the place to find savings whenever a project runs over.

Show the split as a simple chart in the budget document. It starts a useful conversation about whether the balance matches the year ahead, and it makes the tradeoffs visible before they appear as a mid year request for more money.

List the obligations before the wishes

Start with the costs that arrive whether or not anyone plans for them. Domain and hosting renewals, software licenses per seat, support contracts, payment processing fees, certificate renewals, backup storage and the cost of the team that administers it all. Add the dates to a calendar.

Add the known changes. A price increase in a vendor contract, a migration required by an end of life announcement, a compliance deadline. Those items are not surprises if someone reads the notices, and reading the notices is a task that belongs to an owner.

Every recurring contract with its renewal date and owner.
License counts per team and the seats that are no longer used.
Hosting, storage, backup and bandwidth costs with growth assumptions.
End of life dates for frameworks, servers and devices.
Compliance and security work with a deadline.
A contingency line for urgent fixes, sized from last year's actual spend.

Price the work in hours and outcomes

A budget line called website improvements is hard to defend because it has no unit. Break it into work with an estimate and an outcome. Three new service pages, a booking integration, a form rebuild. Each item has a cost, a benefit and a way to tell whether it worked.

Use ranges rather than single numbers for early estimates. A range communicates uncertainty and invites a conversation about scope. A single number invites a comparison with the cheapest quote and a later argument about what was included.

Include internal time. The team that reviews, tests and approves changes spends hours that rarely appear in a budget. If those hours are invisible, the plan assumes unlimited capacity and the work queues behind everything else.

Infrastructure and service costs mapped across a year — Put renewal dates and end of life dates on the same calendar as the projects. Most mid year surprises are visible months in advance.

When an urgent cost appears

Urgent costs are normal. A security patch, a failed drive, a vendor outage that needs a fix. The question is whether the budget has a place for them. A contingency line sized from last year's actual urgent spend removes the need to raid a project every time something breaks.

Decide who can authorise an urgent spend and at what threshold. A clear rule lets the team act quickly without a meeting, and it prevents small emergencies from becoming budget negotiations. Record every use of the contingency with a short reason.

Review the contingency at mid year. If it is exhausted, the pattern is telling you something about the age of the systems or the quality of the support. That is a signal for the next budget, not a reason to cut the maintenance line.

Review quarterly, adjust once

Review the budget each quarter against actual spend and actual outcomes. Adjust the plan once, at mid year, with a clear record of what changed and why. Constant reforecasting creates work and makes the plan less useful as a guide.

Keep the outcomes next to the spend. A line that says 20,000 for a booking integration is less useful than one that says 20,000 to remove forty calls a week. The second version can be evaluated and defended.

Read the vendor contracts

Before the budget is set, read the renewals, the price escalation clauses and the notice periods. A contract that renews automatically with sixty days notice needs a calendar reminder thirty days earlier. A price increase tied to an index needs an assumption in the plan.

Check the seat counts against actual use. Most companies carry licenses for people who left or roles that changed. A quarterly review of active users against paid seats often frees enough to fund a small improvement without new money.

Consolidate where it makes sense. Three tools that each do a small part of the same job often cost more than one that covers two of them. Consolidation has a migration cost, so compare the saving over two years rather than the first invoice.

The cost of ownership

For any new system, budget the first three years, not just the launch. Hosting, support, updates, training, integrations and the internal time to administer it. A system that is cheap to build and expensive to run is a budget problem that appears quietly in year two.

Ask what the exit would cost. A system with a clean export and standard formats is easier to replace than one that holds the data in a proprietary structure. The exit cost is part of the ownership cost even when the exit is years away.

Include the cost of not changing. If the current process takes six hours a week of manual work, that is a recurring line that never appears in a technology budget. Write it down, multiply it by the loaded hourly rate and put it next to the cost of the fix.

A technology budget is a plan for keeping the business running while it changes. Fund the running part first, or the change part pays for it later.
Edgeless Team

Write the plan so a new finance lead can read it without a translation. Name the systems, the dates, the owners and the outcomes. The document is as much a communication tool as a spending limit.

Keep a short list of what the budget does not cover. Assumptions about headcount, new offices, acquisitions or a change in the product line all affect technology cost. Writing them down makes the plan easier to revise when the assumptions change.

Share the document with the people who will spend against it, not only the people who approve it. A budget that lives with finance and not with the delivery team becomes a constraint discovered late. A shared view makes tradeoffs visible while there is still time to choose.

We help teams build technology budgets with renewal calendars, cost models and a clear split between run, change and grow.

Explore software development

The goal is not a perfect forecast. It is a plan that survives a surprise, keeps the base stable and still funds the work that moves the business forward.

Budget

Operations

Planning

Planning a technology budget that survives the year

Let's Talk About Your Project