Engagement 01 · Strategize
The Technology Decision Sprint
A short, paid engagement that answers one question properly: should this business build, buy, configure, integrate, automate or retire? You leave with the decision, the reasoning, the architecture direction and the numbers — and you own all of it, whether or not we ever build anything for you.
Where the sprint sits
One bounded decision, then three possible routes out of it
All three routes are legitimate outcomes. Only one of them earns us more work.
In short
A Technology Decision Sprint is a bounded strategy engagement run before a major technology investment. It maps the current workflow and what it costs, compares the realistic options against that cost, identifies the risks in each, and produces an explicit recommendation with a budget range, an operating-cost estimate and a phased roadmap. The client owns the resulting blueprint outright and is free to implement it with anyone.
When it applies
Situations that trigger a sprint
If one of these is on your desk right now, the sprint is the cheapest next step — because each of them is a decision being made with incomplete information.
You have a quote and no way to judge it
A vendor has priced a build. Nobody internal can tell you whether the scope is right, whether the estimate is real, or whether the thing should be built at all.
Two systems do not talk and people are the integration
Someone exports a file on a schedule. It works until they are on leave, and the error rate is invisible until a customer finds it.
Software that fitted five years ago no longer fits
The business changed. The system did not. Every month there is another workaround, and the workarounds now outnumber the features.
You are being sold AI and cannot price the benefit
The demo was impressive. Nobody has established what the current process costs, so there is no number the AI has to beat.
A platform decision is about to lock you in for years
ERP, CRM, commerce platform, cloud provider. The cost of choosing wrong is measured in years, not in the licence fee.
You are about to rebuild because it feels easier
It usually is not. A rewrite restarts a clock that has already been running, and the reasons the first system got complicated do not disappear.
What happens
How the sprint runs
- 01
Scope the question
A short call establishes which decision is actually being made. Sometimes it is not the one the request named, and that is worth finding out before anyone is billed for a week.
- 02
Map the current state
We sit with the people who do the work and follow it end to end — the systems, the handoffs, the exports, the exceptions and the workarounds nobody documented.
- 03
Price the problem
Staff time, licences, rework, delay, leakage, risk. This becomes the number every option is measured against, and it is usually the first time anyone has written it down.
- 04
Compare the options
Build, buy, configure, integrate, automate, retire. Each is costed to implement and to run, with the assumptions stated so you can challenge them.
- 05
Stress the risks
Data quality, vendor dependency, security, ownership, scale, and what the system does when something upstream fails.
- 06
Recommend and sequence
One explicit recommendation, the rejected options and why, a budget range, an operating-cost estimate, and what to do first versus what to defer.
Deliverables
What you get
Written documents, not a slide deck read aloud on a call. Scope varies with the decision — a platform choice needs a different depth from a single workflow.
You own all of it. The blueprint is yours on delivery, with no restriction on who implements it. If the recommendation is that someone else is a better fit for the build, that is written down too.
- Current-state workflow map
- Business problem definition, in the business's own terms
- Systems inventory and how data moves between them
- Current-state cost model, with the assumptions exposed
- Build / buy / configure / integrate / automate / retire comparison
- Explicit recommendation, and why the other options lost
- Architecture direction and integration map
- Risk register, including failure modes and who owns them
- Security and data-handling considerations
- Implementation phases and a first-version boundary
- Budget range and an annual operating-cost estimate
- Twelve-month roadmap
The uncomfortable part
When we recommend not building
It happens, and it is the main reason to pay someone whose fee does not depend on the answer. Recommendations that have come out of this work include configuring a module the client already owned, integrating two existing systems instead of replacing both, retiring a process that existed because of a customer who had long since left, and waiting two quarters because the data was not clean enough to build on yet.
A build recommendation from a company that also builds is only worth something if that company is willing to give the other answer.
Afterwards
What happens when the sprint ends
You implement it yourself
The blueprint is written to be handed to an internal team or another vendor. That is a legitimate outcome and it is priced as one.
We build or automate it
If the recommendation is to build or automate and you want us to, the sprint becomes the scope. Nothing is re-discovered and nothing is re-billed.
Nothing happens yet
Sometimes the honest recommendation is to wait. You still own the analysis, and it is still true in six months.
Questions
Before you ask
It depends on how many systems and how many people touch the workflow. A single process inside one team is short. A platform decision spanning finance, operations and fulfilment takes longer because the current-state mapping is the expensive part. We scope it on the first call and tell you before you commit.
It is priced per engagement against the scope agreed on that first call, because a single-workflow question and a multi-system platform decision are not the same piece of work. You get the number before anything starts, and the sprint is fixed-scope — if it grows, we say so rather than invoicing the difference.
Access to the people who actually do the work, not only the people who manage it. Read access to the relevant systems where practical. Any quotes, contracts or proposals already on the table. That is most of it.
Yes, and it is one of the more useful times to do it. We have no stake in whether their proposal wins. We read it against your outcome and your economics and tell you where it holds up and where it does not.
Then say so and we will tell you honestly whether the decision needs a sprint first. If the decision is genuinely already made and well understood, we will take you straight to the build rather than sell you a week of analysis you do not need.
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.