The Stratgik method

The Technology Decision Framework

Five questions, in order, that decide whether a business should build, buy, configure, integrate, automate or retire — before anyone specifies a system. It is the work we do first on every engagement, and it is the reason we can tell a client not to build.

Map my technology decision Try the Build vs Buy tool

5 questions6 options, not 1Selection comes last

Five questions, in order

Each is answerable only once the one above it is honest

Most failed technology spend starts at the bottom of this diagram and works upward.

The shape of it

One pass, five questions, no shortcuts

Business outcome

What measurable thing has to change?

Current-state economics

What is the problem costing right now?

Options

What are all the ways to close the gap?

Risk

What could make the right answer fail?

Recommendation

What should the business actually do?

options compared every time — building is one of them, not the default

options priced seriously before a recommendation, including one that writes no code

0-yr

horizon on every comparison, because licence fee versus build quote is the wrong question

named owner for the failure path, or the recommendation is not finished

In short

A technology decision framework is a fixed order of questions that establishes what outcome must change, what the problem costs today, which of the six available options closes the gap, what could make each option fail, and therefore what the business should do. Technology selection happens after that, not during it. Running the questions out of order — starting from a product demo or a build estimate — is how organizations end up owning software that does not fit the business.

The framework

Five questions, in this order

The order matters more than the content. Each question is only answerable once the one before it has been answered honestly.

Business outcome

What measurable thing has to change?

Not "we need a portal". A number that is wrong today and what it should be instead. If nobody can name it, the project has no finish line and no way to be judged.

Done when: You can state the outcome as "X is n today and needs to be m", and someone in the business would recognise both numbers.

What this covers

Revenue: Orders lost at checkout, deals stalled in approval, quotes never followed up.
Margin: Cost per order, cost to serve a customer, licence spend per seat that nobody uses.
Processing time: Hours between an order arriving and it reaching the warehouse.
Capacity: How much more volume the same team could carry.
Errors: Rework, credit notes, wrong shipments, re-keyed data.
Risk: Single points of failure, one person who knows how it works, no tested restore.

Current-state economics

What is the problem costing right now?

Before anyone quotes a build, price the problem. Most technology decisions are made without this number, which is why so many of them cannot be defended a year later.

Done when: The cost of doing nothing is written down as an annual figure, and the business agrees it is roughly right.

Where the annual cost actually sits

Illustrative shape, not one client's numbers

Staff time re-keying and chasing46%

Errors, rework and credit notes18%

Delay — margin lost to slow cycles14%

Overlapping licences and dead seats10%

Revenue leaking between systems8%

Operational risk carried, not priced4%

Staff time is almost always the largest line and almost never the one that gets counted, because the people are already on the payroll.

What this covers

Staff time: People × hours × frequency × loaded cost. Usually the largest line and the one nobody counts.
Licences: What you pay for tools that overlap, or seats nobody logs into.
Errors and rework: What it costs to fix one mistake, times how often it happens.
Delay: Revenue or margin lost because something takes days instead of hours.
Revenue leakage: Orders, renewals and quotes that quietly fall through a gap between systems.
Opportunity cost: What the same people would be doing if they were not doing this.
Operational risk: The cost of the bad day: the outage, the lost data, the failed audit.

Options

What are all the ways to close the gap?

Building is one of six answers, and it is rarely the first one worth testing. Each option gets compared against the same outcome and the same economics, not against a preference.

Done when: At least three options were priced seriously, including one that involves writing no code.

The six options

Buy

Someone already sells this. The work is selection, configuration and migration — not engineering.

Choose it when — Your process is close to standard, and the differences are habits rather than advantages.

Configure

You already own something that does this and nobody has set it up.

Choose it when — A system you pay for is doing 40% of its job.

Integrate

The capability exists in two systems that do not talk, and people are the integration.

Choose it when — Someone is exporting a CSV on a schedule.

Automate

The steps are right; the repetition is the problem.

Choose it when — The rules are stable and the judgement calls are rare and identifiable.

Build

The way you do this is genuinely different, and the difference is why customers choose you.

Choose it when — No product fits without bending the business out of shape.

Retire / stop

The process should not exist. The cheapest system is the one you switch off.

Choose it when — It exists because of a customer, a rule or a person who has since gone.

Risk

What could make the right answer fail?

A recommendation that ignores how it could go wrong is a sales pitch. Risk is assessed against the option, not in the abstract.

Done when: The failure path is designed before the happy path, and someone is named as the owner of it.

What this covers

Implementation complexity: How many moving parts, how many teams, how many unknowns.
Data quality: Whether the data the plan depends on is actually clean enough to depend on.
Vendor dependency: What happens when they change their pricing, their API or their mind.
Security: What new surface this creates and who can reach it.
Maintenance: Who patches it, who upgrades it, what it costs to keep alive.
Operational ownership: Who is responsible at 3am, and whether they know they are.
Scale: What breaks at ten times the volume, and whether ten times is plausible.
Failure modes: What the system does when a dependency is down — and whether it fails toward a human.

Recommendation

What should the business actually do?

An explicit answer, with the reasoning attached and the rejected options recorded. Sometimes the answer is to do nothing yet, and that is a legitimate deliverable.

Done when: Somebody who was not in the room can read the recommendation and understand why the other options lost.

What this covers

The decision: Build, buy, configure, integrate, automate, retire — or wait.
Why not the others: Written down, so the question does not get reopened every quarter.
What it costs: To implement, and then to run, every year.
What has to be true: The assumptions the recommendation depends on, so you notice when one stops holding.
Sequence: What happens first, and what is deliberately deferred.

Why the order pays

The cheapest option is usually invisible from a demo

Price the problem first and the comparison changes shape. A custom build is not wrong because it is expensive; it is wrong when something smaller closes the same gap. The five-year view is where that becomes obvious — and it is the view almost nobody draws before signing.

Implementation price is the smallest part of what you will pay. What a decision costs to own — maintenance, licences, the workarounds built around a product that nearly fits — is where the difference between options actually lives.

Run your own numbers

Five-year cost of ownership

Shape, not scale — the comparison sticker price hides

Doing nothing is the line most decks leave off. Drawn in, it is usually what makes the cheapest real option obvious.

Worked example

The same request, run through the framework

The request as it arrives

“We need a custom order management system.”

0 days

for an order to reach the warehouse today

<0 hrs

what it has to become to keep the delivery promise

of the catalogue whose product codes do not match across systems

01 — Outcome

Orders take two days to reach the warehouse. They need to take under four hours, because the delay is costing next-day delivery promises.

02 — Economics

Four people re-key orders for roughly three hours a day between the storefront and the ERP. Add the credit notes caused by typing errors. That is the annual cost of the problem, and it is the number every option gets compared against.

03 — Options

A new system is one answer. So is an integration between the two systems that already hold the data. So is turning on a module in the ERP that was bought and never configured.

04 — Risk

The integration depends on product codes matching across both systems. They do not, for about 6% of the catalogue. That has to be fixed regardless of which option wins — and if it is not surfaced now, it surfaces in production.

05 — Recommendation

Fix the product data, integrate the two systems, and do not build an order management system. The custom build was a real option; it was simply the most expensive way to solve a problem that was actually about data moving between two systems that already existed.

This is not a hypothetical shape. It is the most common one: the request names a system, and the outcome turns out to need something smaller.

What it rules out

Things this framework will not let you do

Start from a product demo. A demo shows you what a vendor built for someone else's outcome.

Compare on sticker price. Implementation cost alone ignores what each option costs to run for the next five years.

Automate an unexamined process. Automating a broken process makes it break faster.

Default to build. The request arriving as a system description is not a reason to write one.

Approve without an owner. A recommendation with no named owner for the failure path is not finished.

Skip the cost of doing nothing. Without it, every option looks expensive.

Questions

Common questions about the framework

When the way you do the thing is genuinely different from how everyone else does it, and that difference is part of why customers choose you. If the difference is habit rather than advantage, configuration or integration will be cheaper to buy and far cheaper to own. Build is also right when no product covers the workflow without forcing the business to reshape itself around the software.

When the process is close to standard, a mature product exists, and the gaps are things you could change about how you work. Buying trades control for speed and for somebody else carrying the maintenance. The real comparison is not licence fee versus build quote — it is total cost of ownership over five years, including the cost of the workarounds you will build around the product.

When the steps are already correct, the rules are stable, the volume is high enough for the saving to matter, and the judgement calls are rare and identifiable — so the automation can hand them to a person instead of guessing. If the process is wrong, fix it before automating it.

The arithmetic is the same as any automation: time saved multiplied by frequency multiplied by loaded cost, minus what it costs to run and supervise. AI changes the second half of that equation, because inference has a running cost and outputs need checking. It pays when the work is high-volume, the cost of a wrong answer is low or catchable, and a human is in the path for the cases that matter.

Then that is the deliverable. A decision not to spend is a legitimate outcome, and it is one of the few pieces of advice you cannot get from someone who only earns money by building.

Yes, and the page is written so that you can. What an outside team adds is the current-state economics — the part organizations consistently underestimate because the cost is buried in people already on the payroll — and a recommendation from someone with no stake in which option wins.

Engagement

Technology Decision Sprint

We run the framework on your situation and hand you the blueprint — whether or not we build it.

See the sprint

Free tool

Build vs Buy calculator

Stage 03 in a form you can run yourself in a few minutes. No email required for the result.

Open the tool

Capability

Technology strategy

Roadmaps, architecture direction, vendor evaluation and modernization decisions.

Strategize

Tell us what isn't working.

One process, one system, one decision you are stuck on. We will come back with how we would approach it, what it would take, and whether it needs building at all.

Talk about the problem See what we've built

The Technology Decision Framework

One pass, five questions, no shortcuts

Five questions, in this order

Business outcome

Current-state economics

Options

Risk

Recommendation

The cheapest option is usually invisible from a demo

The same request, run through the framework

Things this framework will not let you do

Common questions about the framework

Technology Decision Sprint

Build vs Buy calculator

Technology strategy

Tell us what isn't working.

Strategy first. Technology that follows through.