What Actually Counts as a "Minimum Viable Deployment" — Not Just Another Demo?
Problem card in hand, the business side's next question is always: "So when do we get to see results…
Make it work, make it right, make it fast. — Kent Beck, software engineer
Problem card in hand, the business side's next question is always: "So when do we get to see results?"
Is your first instinct "let me build you a demo"?
But there's a common trap here: many teams understand an MVD (Minimum Viable Deployment) as "a scaled-down demo" — cut 70% of the features and end up with something that's neither one thing nor the other. The result validates nothing and wastes time on top of it.
A demo optimizes for "looking like it works." An MVD optimizes for "actually measuring whether it works."
These are two different things. What kind of "small" is the right kind, and how do you avoid this trap — that's what this chapter is here to sort out.
I. The Gap
A practitioner at an applied-AI company in the insurance industry wrote publicly about their first day: "The first time we run a new agent against a customer's real workflow, it gets just a little over 70% of it right. On a recent premium audit deployment, our agent read a mess of inbound documents, structured and reasoned over the data, and wrote it back to an antiquated policy admin system. Day one, the customer's own experts graded it at ~70% accuracy. The number we promised in our contract was >98%."1 His next line is the interesting part: "Everything interesting about my job lives in that gap."1
Why do those 28 points matter? Because you will never see them in a demo environment — demo data is clean, edge cases are friendly, there's no legacy baggage, and hitting 100% is the norm. The gap only shows itself in a real environment, and the later it's discovered, the more it costs: sign a 98% contract, then discover the starting point is 70%, and every one of those points has to be closed under the customer's watchful eye.
This is exactly why MVD exists. It's not there to deliver a scaled-down system — it's there to measure the shape of that real gap as early as possible: with the smallest possible engineering investment, inside the customer's real environment, against a real pain point, verify whether value can actually be created.
Worth clarifying the difference between MVD and MVP while we're at it: an MVP (Minimum Viable Product) validates "should this product exist at all," and the judge is the market. An MVD validates "can this solution produce value for this specific customer," and the judge is that customer's actual business owner.
One letter apart, and the difference is who's judging. This also explains the brutal reality of enterprise delivery: a solution validated successfully at ten prior customers can still fail at the eleventh — different data foundations, different organizational inertia, a differently-shaped pain point. Value can't be inherited from the last customer; it has to be re-validated on this one. So MVD has no template answer, only a methodology.
II. The Three "Real" Conditions
The line between MVD and a demo comes down to three "real" conditions: real data, real users, real baseline. Miss any one of them, and what you've delivered is still a demo wearing a different name (see Figure 7-1).
Figure 7-1: An MVD narrows the scope, not the real conditions required for production-grade validation.
Real data. Validating against a customer's sanitized sample data, or demo data you constructed yourself, is the first brick in the graveyard of proof-of-concepts. This isn't about ceremony — it's that real data is full of landmines: field meanings that don't match the documentation, 30% null values, three-year-old encoding rules, and worst of all, data that itself records a broken process. A solution that holds up on fake data hits fields that don't exist in any document the moment it goes live — and by then the real price has already been paid. So there's exactly one hard requirement: the customer has to bring their own real business data. It can be sanitized, it can be a sandbox copy — but the distribution has to be real.
Real users. At least one front-line user, actually using it every week and actually giving feedback — not a product owner using it on their behalf, not a courtesy click-through at the acceptance meeting. The test is plain enough: if that user takes a week off, does the work still find its way to this system? A demo performs for the decision-maker; usage grows in the user's own hands. MVD needs the latter.
Real baseline. Before going live, measure the baseline of the manual process: how long the task currently takes, how often it's wrong, what it costs. Without a baseline, the word "improvement" has nowhere to stand — this is the execution-layer continuation of Chapter 6's filter three (verifiability): whatever baseline got promised when that filter was passed has to become a set of numbers written down by the time you reach MVD.
Only once all three "real" conditions are met does an MVD start producing what a demo never can: a measurable real gap, and a judgment that's been tested by actual use.
III. Cut the Scope, Not the Value
The three "real" conditions make the gap measurement real; the next question is scope — how small do you cut, and how?
The right way to cut "small" is three cuts: cut the number of processes — build one end-to-end process, not a platform; cut the user base — serve one team; cut the agent's boundary — let the agent take over only the most measurable segment of the process, leaving the rest to people.
All three cuts stand on one non-negotiable rule: what shrinks is the scope, not the value. The most common mistake is understanding an MVD as "a gutted version of the big plan" — cut 70% of the features and end up with something that's neither one thing nor the other. The right move is to cut breadth, never depth: don't aim for "smart customer service covering the whole company" — aim for "covering only returns-and-exchanges tickets, but doing it end-to-end with zero human intervention"; don't aim for "supply-chain optimization across the whole group" — aim for "scheduling conflicts on this one production line, but genuinely saving 20 person-hours every week"2. The entry point has to be small so it can be deep; and once it's visibly deep, the business side notices it with their own eyes — and starts spreading the word on their own.
As for "how small is small enough," there's a ready-made test: "if users can use it without changing their existing habits, that's enough; if they have to reshape their workflow just to use your system, you've gone too far."3 A professional team once spent several hundred thousand yuan and three months building full-chain AI automation, only to be outperformed by a simplified version a sixty-something school principal hand-built in three days — he only automated template generation, leaving every other step to be filled in by hand as before, and other principals loved it, precisely because it didn't force them to change their habits.
One comment gets right to the point: "the measure of success was never how advanced the technology is — it's whether the person using it still wants to open it tomorrow."3
Beyond scope, there's one more boundary to draw: should an MVD accommodate the customer's legacy systems?
Practice has settled on a middle path: "read old, write new" — deeply compatible on the data side, reading from wherever the customer's data actually lives (read-only, never write), even if that's a legacy mainframe or a spreadsheet on a shared drive; never coupled on the architecture side — code lives entirely inside your own controllable boundary and talks to the legacy system only through an interface, never gets pushed into it.
The reasoning is out in the open: a solution still in validation has better than even odds of being thrown out and rewritten, and the deeper the coupling, the more that costs; writing into a legacy system means going through change management, which runs on a monthly cycle — flatly incompatible with a weekly pace.
On process, defer to human habit rather than system habit — if the user's core action happens in a spreadsheet and email, the interface should live inside a spreadsheet plug-in and email too. A practitioner in China summed it up this way: the customer's core system has been running for a decade, so start with a lightweight plug-in on the periphery — "the test is simple: does this change force the user out of the system they already know. If it forces them out, hold off. If it doesn't, push forward."3
There's one more easily-overlooked principle: an MVD is the first step of a staircase, not a miniature version of the destination.
One investment firm's weekly-report automation climbed three steps — first a conversational format that cut out the writing, then an upgrade to voice generation, and finally cutting out even the voice step, reading work logs directly and auto-summarizing the weekly report. Every step could be accepted or halted on its own, and real use of the previous step became the requirements evidence for the next one4. Try to jump straight to what step three looks like, and you usually can't even stand on step one.
IV. Measured in Weeks, Not Months
The third non-negotiable rule is fixing a hard deadline: an MVD's validation cycle runs in weeks, not months — Palantir's own bootcamp compressed this down to one to five days, and public reporting puts the fastest go-lives at four weeks, with typical deployments running four to eight weeks2. The point of the deadline isn't speed for its own sake — it's to force both sides into honest trade-offs: whatever can't demonstrate value within these few weeks isn't core value yet. A six-month "minimum validation" will almost inevitably regrow into a big project that wants everything — which is just another groundbreaking for the graveyard of proof-of-concepts.
A two-week sprint can be broken down by the day:
| Day | What Happens |
|---|---|
| Day 1 | On-site alignment: write the "single point problem" with the customer as one sentence, and the acceptance metric as one number |
| Days 2–3 | Connect data: hook up only the minimum dataset this problem needs; lock down permissions, sanitization, and export method on the spot |
| Days 4–5 | Build the skeleton: get the minimum prototype running — one that can query data and answer questions |
| Days 6–8 | Plug into the real business flow: one or two real users start actually using it to do their work |
| Day 9 | Collect usage traces and the issue list |
| Day 10 | Demo and decision: not a feature demo for the IT department, but showing the business side "here's where your problem stands now" — decide on the spot whether to scale up, adjust, or call it off |
The customer side has three matching commitments of its own: a business-side owner who can actually make the call, present throughout; an internal data-literate point of contact, present the whole way; and access to real data in place on day one, not "still going through the process." Miss any one of the three, and a two-week sprint is very likely to slide back into a traditional proof-of-concept2.
FDE: The Delivery Paradigm Revolution sums up this same rhythm as four steps: understand the business — walk in and map the business chain, the pain points, and the value lever first, without rushing to write a prompt or stand up an agent; build collaboratively — business experts and engineers turn the scenario into an agent, a workflow, or a prototype together, not the engineering team working alone; use tooling to guarantee quality — generate a test set from real chat logs, tickets, and business data, then run automated evaluation and A/B comparison; validate the business outcome — compare the AI group against the human group step by step, using people-facing metrics like reach rate, response rate, and conversion rate to prove the value. All four steps come down to one sentence: sell the outcome, not the software — customers don't pay for "we used AI," they pay for the business actually getting better.
V. Being Thrown Away Is the First Version's Destiny
MVD is done — what happens to the code? McGrew laid out the two-team division very clearly: an FDE delivers a custom implementation fast, on the customer's site — built for this one customer only, roughness allowed, bugs owned; the product and engineering team's job is to look at that implementation and think from first principles about how to generalize it for the next five or ten customers, turning a one-off custom build into a reusable product5. One version of code shouldn't be asked to do both jobs at once — run in ten days and stay maintainable for ten years.
Which is exactly why the profile to avoid when hiring for the MVD stage is so specific: someone who cares about craftsmanship, insists on polishing the abstraction layer until it's exactly right, wants to write software built to be maintained for a dozen years — because that isn't this stage's job.
The code a fast-prototyper writes is sometimes beautiful — "but usually not, and that's not the key part of the job either. What matters is someone who can actually go deliver that outcome in the form of software, on a timeline. It may be that the first version they write has to be thrown away, and they write a complete second version."5
Put those two things together and it's clear: what an MVD actually accumulates as an asset isn't code — it's test questions and understanding.
The test questions are the eval set — given this customer's real inputs, which answer is the right one. The understanding is process comprehension — which requirements are general, which are specific to this one customer, which pitfalls the next customer will hit too. The code gets thrown away and rewritten; both of these travel forward intact. This also directly corrects a common fixation — "turn the MVD code straight into production code": whatever development time that saves is nowhere close to the cost of patching custom code into a production system, which is exactly what Chapter 9 unpacks.
Here's a self-check list to compare against:
Modifying demo code straight into an MVD — every assumption baked into the demo data leaks into the baseline, and the measured gap is fake;
Turning an MVD into a feature bundle — scope goes out of control, two weeks becomes two months, validation turns into development;
"Go live first, figure it out later," skipping the baseline — value can never be proven afterward, and there's nothing to say at the renewal negotiation table.
One last point — the exit condition: an MVD stage is allowed to launch without a complete approval chain, without monitoring, without a degradation plan — but it is not allowed to launch without an eval set. It's the one thing an MVD must start building from day one, and how to build it is Chapter 12's subject. Only with a working eval set and a measured real gap in hand can you answer the question the customer is bound to ask next — "so, when can this go live?" That's what Chapter 8 covers.