Before approving your 2027 technology budget: six questions to answer

Budgets for 2027 are being drafted, challenged and approved right now. Somewhere in most of them sits a technology line: a new platform, a system that needs replacing, an integration that keeps getting postponed. This year there may also be a line labelled “AI” or “automation”, often written after a demo that impressed everyone in the room.

A budget line is a promise to spend money. It is not yet a decision about what the money will achieve. The six questions below are the ones we work through before a technology line is approved, so that the number in the spreadsheet is one someone can defend in March, not only in November.

Why the cheapest moment is before approval

Examining the options behind a technology line takes a few weeks of attention. Once the line is approved, the decision tends to harden on its own: a vendor gets chosen so the money can be spent, the team plans around it, and other projects are scheduled against it. Reversing it six months later means paying twice, once for the thing that did not fit and again for the thing that replaces it.

That is why an independent second opinion costs least exactly when it feels least necessary: before the number is fixed.

The six questions

1. What exactly are we deciding, and by when?

“Invest in AI” is a direction. “Stop re-typing supplier invoices into the ERP by the end of Q2” is a decision: it names an outcome, a boundary and a date. The narrower version is easier to cost, easier to test and easier to say no to, which is exactly what makes it a better budget line.

A good answer fits in one sentence and includes a date. A warning sign is a line named after a technology instead of an outcome.

2. What does doing nothing cost?

Every technology line competes with the option of not spending the money. Put a figure or a named risk on the status quo: hours spent every week, errors every month, a system whose support ends next year, a customer requirement you cannot meet today.

Sometimes the honest answer is that waiting a year costs very little. That is a legitimate outcome of this question, and it frees budget for something that matters more.

A good answer is a number or a specific risk. A warning sign is “everyone else is doing it” as the only reason.

3. Which constraints cannot move?

List them before comparing any options: the skills of the team that will run it, the systems it has to connect to, the rules your data is subject to, the date it has to work by, the ceiling on the budget. Fixed constraints eliminate options faster than any feature comparison.

A good answer is a short list written down before the first vendor call. A warning sign is a constraint discovered after signing, such as a tool that cannot connect to the accounting system, or that stores data somewhere it is not allowed to be.

4. What will it cost to run in the second year, not just to build?

Budget lines usually capture the build or the purchase. The running cost arrives later: hosting, per-user licences, integrations, monitoring, maintenance and updates, security patches, and the time of the person who looks after it.

AI features add one more line that is easy to miss. Usage is often billed per request, so the cost grows with adoption. The bill during a small pilot says little about the bill once the whole company uses it every day.

A good answer shows a year-two figure next to the build figure. A warning sign is a budget that stops at launch day.

5. What are we assuming, and what can we test before committing?

Write two columns: what is confirmed and what is assumed. Every plan contains assumptions. The risk is not knowing which parts are which.

Then pick the riskiest assumption and test it cheaply before the full commitment: a few weeks of pilot on real historical data, a prototype in front of the people who will use it, a conversation with a company already running the platform you are considering. This is where fast, AI-built prototypes earn their place: they are one of the cheapest ways to test an assumption before paying for the real build. We wrote about what those prototypes can and cannot prove in what a vibecoded prototype still needs before it can run a business.

A good answer names the riskiest assumption and the test that will settle it. A warning sign is a business case where every number is an estimate nobody has checked.

6. What would it cost to change course, and who owns the result?

Some decisions are easy to undo, such as a monthly subscription to a tool. Others are not, such as moving core business data onto a new platform, or a custom build nobody on your team can maintain. Know the exit cost before committing: how your data comes back out, what the contract allows, what happens to every system connected to it.

Then name one person who owns the result after go-live. A vendor can support a system; only someone inside the business can own the decisions it makes.

A good answer states the exit cost and a named owner. A warning sign is “the vendor handles that.”

A worked example

Take a case invented for this article. A distribution company with around forty people has a line in its draft 2027 budget called “AI customer support”, based on a vendor demo that went well.

Run through the six questions, the line changes shape.

The decision. Talking it through, the real problem turns out to be narrower: most incoming emails are customers asking where their order is. The decision becomes “answer order-status questions automatically by the end of Q1.”

Doing nothing. Two people spend part of every day answering those emails by hand, and replies slow down in peak season, exactly when customers are least patient.

Constraints. Answers must come from the existing order system. Customer data has to stay where it is stored today. There is no budget for a new hire to maintain anything.

Running cost. The demo tool charges per conversation, so its year-two cost at full volume is far above the pilot quote. A simpler automated reply connected to the order system handles the routine questions at a fixed cost, and AI is kept for the messages that actually need it.

Assumptions. The biggest one is that answers can be generated accurately from the order data. A four-week test on last quarter’s emails settles it before anything is signed.

Changing course and ownership. Order-status replies go out automatically. Refunds and complaints are drafted, then approved by a person. The operations lead owns the workflow.

The approved line ends up smaller and more specific: a defined outcome, a test phase, a year-two running cost and a named owner. It may cost less than the original line or it may not. Either way, it is a number someone can defend.

What goes into the budget: a one-page decision template

Each technology line that reaches approval should come with one page that answers the six questions: the decision, the cost of doing nothing, the fixed constraints, the options compared on the same criteria, what is confirmed and what is assumed, the cost to change course, the owner, and the recommended next step.

Download the free one-page decision template (PDF). No sign-up needed; print it or fill it in on screen. If you would rather work in your own document, copy the template below:

TECHNOLOGY DECISION BRIEF
Investment / budget line:
Prepared by:                         Needs approval by:

1. The decision (one sentence, with an outcome and a date):
2. The cost of doing nothing (a number or a named risk):
3. Constraints that cannot move (team, connected systems, data rules,
   deadline, budget ceiling):
4. Options, compared on continuity, cost to build, cost in year two,
   team capability, security, flexibility, maintainability and time:
   - Option A:
   - Option B:
   - Doing nothing:
5. Confirmed:
   Assumed:
   Riskiest assumption, and how we will test it before the money
   is committed:
6. Cost to change course (data export, contract, connected systems):
   Owner of the result after launch:
7. Recommended next step:

If a line cannot fill that page yet, the answer is not necessarily “no”. Approve a smaller discovery or pilot first: enough to confirm the requirement, test the riskiest assumption and calculate the real operating cost. It can be its own, much smaller budget line, and a few weeks of clarity, paid for before a year of delivery, is often the best-spent money in a technology budget.

If a technology line is waiting for approval

Our IT and business consultancy work is built for this moment: independent, implementation-informed guidance on decisions that will affect cost, risk and maintainability for years.

If you have a technology line in your 2027 budget, send us through the contact form three things: the line as it is currently written, what it is meant to achieve, and the date it needs to be approved by. We will tell you which of the six questions it already answers, and which ones to settle before the money is committed.