A technology budget that serves the roadmap

Balancing cloud cost, delivery speed and business value, and knowing when optimising spend is the wrong job.

By Elias Limouni · 12 November 2026 · 6 min read

A technology budget is a statement of priorities. Tie each line to a roadmap outcome, not to last year's spend.
Track cost to serve a customer and cost per feature delivered, not just the total cloud bill.
Build what customers choose you for; buy what every company needs. Revisit the line as you grow.
Optimise cloud spend once the product has settled and costs grow faster than usage, not while you are still finding fit.

Start from the roadmap, not the invoice

Most technology budgets I am asked to look at are built backwards. Someone takes last year's cloud bill, the engineering payroll and a list of software subscriptions, adds an allowance for growth and calls it a plan. It is a forecast of habits, not a budget. It tells the board what the company spent, not what the spending is for.

A budget that serves the roadmap starts at the other end. Take the three to five outcomes the business needs from technology over the next year: a new product line live, enterprise onboarding without engineers in the loop, a platform that passes a large customer's security review, the reporting a regulator expects. Then ask what each one costs to deliver in people, infrastructure, tools, third parties and the time of the people who are not engineers.

Whatever is left, the spend that cannot be traced to an outcome or to keeping the lights on, is the first place to look. Not necessarily to cut. Some of it is insurance and some of it is learning. But it should be visible and deliberate rather than inherited.

Think in unit costs

The total cloud bill is a poor management number. It goes up when the business grows, which is good, and when nobody is watching, which is not, and the headline figure cannot tell you which. Unit costs can. Two are worth tracking from early on.

Cost to serve a customer: infrastructure, third-party services and support effort per active customer or account, per month. If it rises while the product stays the same, something is drifting.
Cost per feature delivered: what it takes, in people and tooling, to get a meaningful change into customers' hands. It is rougher, but it shows where the team's time really goes, which is often maintenance, manual releases and rework rather than the roadmap.

Neither needs to be precise. A figure you trust within a sensible margin, reviewed monthly, beats a perfect one produced once a year. The point is the trend and the conversation it starts: why did this move, and is that what we wanted?

Unit costs also make board reporting easier. “Our cost to serve each customer held steady while usage grew” is a statement a non-technical board can engage with. “The cloud bill went up again” is not.

Build what makes you different, buy the rest

Build versus buy shapes a technology budget more than any other decision, and it is usually made one tool at a time, without a rule. A simple one helps: build what customers choose you for, and buy what every company needs.

Authentication, payments, email delivery, monitoring and most back-office workflows are solved problems. A well-chosen product costs a subscription. Building your own costs engineering time for as long as it exists, because whatever you build you also maintain, secure and explain to auditors. The pricing logic, the matching engine, the workflow that keeps customers with you: that is where your engineers' hours should go. Three questions settle most cases.

Is this part of why customers pay us? If not, lean towards buying.
What does it cost to own for three years? Include maintenance, security patches, on-call cover and the knowledge that leaves when the person who built it does.
How hard is it to leave? Prefer suppliers with clean data export and standard interfaces, so today's purchase does not become tomorrow's lock-in.

Revisit the answers as you grow. A product that was the right purchase at ten customers can be the wrong one at a thousand, when per-seat or per-transaction pricing outgrows what an in-house version would cost. That is a good problem to have, and a decision to take with numbers rather than instinct.

When to optimise cloud spend, and when not to

Cloud cost optimisation is satisfying work. It is measurable and engineers enjoy it. At the wrong moment it is also a way to spend a team's best weeks saving money the business did not need to save.

Before product–market fit, speed of learning matters more than efficiency. An oversized database, a managed service that costs more than running your own, a few environments left on: these usually cost less than the engineering time it takes to tune them, and far less than shipping the next experiment a month late. Put basic guardrails in place, such as budgets and alerts, tags that show which product spends what, and a habit of switching off what nobody uses. Then get back to the roadmap.

Optimisation earns its place when the picture changes:

the product and its architecture have settled, so savings will last;
cost to serve is rising faster than usage or revenue;
infrastructure has become a material line in gross margin, the kind investors and acquirers ask about;
a commitment such as reserved capacity would lock in a discount on load you are confident you will still have.

Even then, run it as a short, bounded piece of work with a target, not an open-ended project. The biggest wins are usually unglamorous: right-sizing, deleting what is unused, storage lifecycle rules, and fixing the handful of queries or jobs that do most of the damage.

A one-page budget framework

This is the structure I use with leadership teams. It fits on a page, which is the point: if it does not, nobody reads it at the quarterly review.

Technology budget checklist

Name the three to five roadmap outcomes for the year, each with an owner and a date.
Assign people, infrastructure, tools and third-party costs to each outcome.
Separate run costs (keeping the lights on) from change costs (moving the roadmap).
Track cost to serve per customer and review it monthly.
Apply the three build-or-buy questions to every new tool or platform above an agreed threshold.
Set cloud budgets and alerts, and tag resources by product and environment.
Hold an explicit reserve for learning and the unexpected.
Agree in advance what would trigger a cloud optimisation sprint.
Report to the board in outcomes and unit costs, not supplier invoices.

The budget is a conversation

A good technology budget does not settle the argument between cost, speed and value. It makes the argument explicit, so the founder, the finance lead and the engineering team are trading off the same things, with the same numbers, in the same room. Keeping that conversation honest is a large part of what a CTO is for.