You have one workflow that looks worth automating, an estimate on the table you cannot defend, and someone upstairs who wants a number before releasing budget. Two steps sit below the build, and they cost $750 and $20,000. From the outside they look like the same purchase — an expert review, delivered in writing — and that resemblance is the trap.
They are not the same purchase, and the difference is neither price nor page count. A scoping session ends in a decision: a written plan, a scope, a budget range, and a go / no-go you can hand to whoever controls the money. A system design ends in a decision and a machine — the architecture, a written build plan, a fixed-price quote for the build, and a working spike that runs the named workflow end to end against your real data, inside your stack.
| AI Scoping Session | System Design | ||
|---|---|---|---|
| Price | $750 | $20,000 | |
| The question it answers | What should we do, and is it worth doing at all? | Will this hold up in our stack, and what will it actually cost? | |
| What you leave with | A written plan, a scope, a budget range, a go / no-go | Architecture, a written build plan, a fixed-price Build quote, and a spike running the named workflow against your real data | |
| The target it is held to | You get the plan and the recommendation, or the fee is refunded | The spike runs the named workflow on the named dataset in your stack, or the fee is refunded | |
| Where the fee goes | Credited toward the Design or any Build | Credited toward any Build |
Neither step is a formality, and the cheaper one carries the more dramatic record. A major US TV network had already received a quote to build a full software system for a workflow that did not require one. The scoping session ML LABS ran stopped that build before it started, and their AI Program Manager put the outcome on the record:
Omar delivered in two weeks what our team estimated would take six months. The scoping session alone saved us from a $200K mistake. He operates at a level you rarely see in this industry.
— AI Program Manager, a major US TV network
Sometimes the deliverable is don't build this.
When The Answer Is Don't Build
The scoping session exists because a build that should never have been authorized cannot be rescued by good engineering downstream. The population data says this is exactly where the money goes: the share of generative-AI projects abandoned after proof of concept (Gartner, 2024) is projected at 30% by the end of 2025, and enterprise adoption research (BCG, 2024) across roughly 1,000 executives found only about a quarter of companies had moved past proof of concept into tangible value.
Those are not model failures. Both research on AI project failure patterns (RAND, 2024) and research on AI project derailment (HBR, 2023) locate the damage upstream of the model, in the gap between the business outcome intended and the technical system actually being built. A study on requirements engineering for AI-intensive systems (Ahmad et al., 2022) found that ambiguity between business intent and technical interpretation is a common upstream cause of downstream delivery problems. The failure is authorized long before it is engineered.
So the question a scoping session answers is not how would we build this. It is should this be built at all, and if so, which one first — and that question has to be closed before deeper work has anything to grip. If competing workflows are on the table and none of them has a named owner or a written success condition, the work of choosing the first use case has not been done, and $20,000 will buy a slower, more expensive version of that same choice.
The step is priced so the answer is allowed to be no. At $750, credited toward whatever comes next, it is the only step on the ladder whose best possible outcome is that you spend nothing else.
What A Running Spike Settles
Once the workflow is chosen, the question changes shape. It stops being what should we do and becomes will this actually work here, and what will it cost — and that is the question a document cannot close. An architecture document cannot fail. It has no data, no auth, no rate limits, and no schema that quietly disagrees with its own documentation; it is a description of a system that has never been asked to exist.
Research on hidden technical debt in ML systems (NeurIPS, 2015) named the reason a decade ago: the model is a small fraction of a production ML system, and the glue around it — data plumbing, configuration, evaluation, the seams between services — is where the cost and the failure live. A plan describes the model well. It describes the glue from memory. That gap is also why the cost gradient is so steep: the classic finding on software defect reduction (IEEE, 2001) is that fixing a problem after delivery costs roughly a hundred times more than fixing it while requirements and architecture are still on paper.
In the HL7 result-delivery layer we built for HeartSciences — the clinical messaging system that carries AI findings back into the hospitals that ordered them — the wall was never the standard. The message any given EHR will actually accept depends on site-specific configuration, vendor-specific requirements, and organizational policies that vary across every hospital deployment. No document predicts which of those will reject your message. Running code against the real endpoint finds out, and a paper exercise never will.
That is what a spike is for, and it is not sold on trust. Targets are written into the contract before work starts, and on both Design steps a missed target is a refund:
The target is fixed in writing at kickoff: the named workflow, the named dataset, the path the spike must demonstrate in your stack. If it doesn't run, full refund. Disliking the recommendation is not a miss.
Read the last sentence twice. The refund is tied to the spike, not to the verdict: if it runs the named workflow on the named data, the target is met — and if the honest recommendation on the far side of it is don't build this, you now have that answer backed by running code instead of an opinion. ML LABS has taken more than ten heavy-workload systems to production over fifteen-plus years, across healthcare, telecom, PropTech, and finance, and a spike is simply how a design stops being an argument: it runs the named workflow on the named data, or it does not, and both outcomes are worth more than a document that can do neither.
The second deliverable is the one that ends the budget argument. A vendor estimate is a hope with a number attached; a fixed-price Build quote from an engineer who has already run the workflow once, in your environment, is a commitment. Absorbing that fee is the whole design of the step — an AI system design credits in full toward the Build it prices, which makes it the shortest path from an argument about which pilots deserve production to a number you can defend. Each of its deliverables carries its own standard, and what a good system design actually contains takes them one at a time.
The Access The Spike Needs
The system design has one hard prerequisite, and it is not technical. The spike has to run against something real, which means someone on your side names the workflow, names the dataset, and grants access to it — one technical owner, empowered to make those calls. Where law or security policy blocks direct access, the spike runs inside your VPC against a de-identified or synthetic extract, and either way the scope of what it must demonstrate is fixed in writing at kickoff.
That prerequisite is the honest boundary between the two steps. If nobody can produce a named workflow, a named dataset, and an owner who can grant access to it, the $20,000 has no target to hit, and it will buy a slower and costlier version of the $750 conversation. Start lower on the ladder — the credit means the order costs you nothing.
First Steps
- Write the buying question in one sentence. If it starts with should we or which one first, a scoping session closes it. If it starts with will this work in our stack or what will it really cost, only running code closes it.
- Name the dataset and the owner. Before considering the Design step, identify the exact data a spike would run against and the one person who can grant access to it. If either is missing, that absence is itself the finding.
- Write down the build budget at risk. Both steps below it are credited toward it, so the only unrecoverable spend on this ladder is a build authorized against a target nobody wrote down.
Sequence The Steps, Bank The Credit
Run them in order and let the ladder's own mechanics make the first decision cheap. Buy the step whose question you can actually state today. If that question is still what should we do first, and is it worth doing, the answer comes back as a written plan and a go / no-go — and if the honest answer is that nothing should be built, you paid $750 to find that out. If the question has already moved to will this hold up in our stack and what will it cost, the answer comes back as running code and a fixed price, and the argument about the number ends there.
Bring the one workflow you cannot stop arguing about to an AI scoping session: one decision, a written plan, a scope, a budget range, and a next step you can take to the people who control the money. The $750 credits toward the Design and the Design credits toward the Build — each within a window the service pages state — so the only cost of starting at the bottom of the ladder is the order in which you did it. And if the plan that comes back says the system should not be built at all, that is not a refund case. That is the product.
References
- Gartner. 30% of Generative AI Projects Will Be Abandoned After Proof of Concept by End of 2025. Gartner, 2024.
- Boston Consulting Group. AI Adoption in 2024: 74% of Companies Struggle to Achieve and Scale Value. BCG, 2024.
- RAND Corporation. Analysis of AI Project Failures. RAND Corporation, 2024.
- HBR Editors. Keep Your AI Projects on Track. Harvard Business Review, 2023.
- Ahmad, K., Abdelrazek, M., Arora, C., Bano, M., & Grundy, J. A Systematic Mapping Study on Requirements Engineering for AI-Intensive Systems. arXiv, 2022.
- Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D., Chaudhary, V., Young, M., Crespo, J., & Dennison, D. Hidden Technical Debt in Machine Learning Systems. NeurIPS, 2015.
- Boehm, B., & Basili, V. Software Defect Reduction Top 10 List. IEEE Computer, 2001.
