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

Five questions, in order

Each one is only answerable once the previous one is honest

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

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.

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.

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.

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.

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.

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

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.

Option	What it means	Choose it when
Buy	Someone already sells this. The work is selection, configuration and migration — not engineering.	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.	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.	Someone is exporting a CSV on a schedule.
Automate	The steps are right; the repetition is the problem.	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.	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.	It exists because of a customer, a rule or a person who has since gone.

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

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.

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.

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

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.

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.

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

Worked example

The same request, run through the framework

The request as it arrives

“We need a custom order management system.”

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 options on implementation price alone, ignoring what each costs to run for the next five years.
Automate a process nobody has questioned. Automating a broken process makes it break faster.
Treat "build" as the default because the request arrived describing a system.
Approve a recommendation with no named owner for the failure path.
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