The minimum viable deployment has three rules

Two teams can spend the same week building the same narrow thing on the same customer's system, and only one of them is running a minimum viable deployment. The difference is not the size of the build. It is who is allowed to rule on it.

An MVP answers to a market: strangers, later, in aggregate, after release. An MVD answers to one customer's own business, this month, on that customer's own data. The artefact can be identical; the referee is not. Once you accept that, three rules stop being advice and become conditions.

One referee changes the design

Because the judge is a person you can name, an MVD can be designed for that person. An MVP cannot be, because you are guessing at a population. Three consequences follow.

A sample of one is not a weakness. You are not estimating how a market will behave; you are testing whether one process, with its real exceptions, can run. Asking "is one enough" imports a statistical worry into a question that is not statistical.

You can interview the customer before anything is built. Sitting next to the person who will use the thing, and watching them do the work, is the cheapest evidence available and the one most often replaced by a meeting.

The deliverable is a verdict, not a system. Something built in a week and thrown away after a decisive review has done its job; something that survives but produces no verdict has not. Write the verdict down with a date and the name of the person who gave it, or the week bought a mood.

Rule one: real data, no exceptions

Real means the shape the work actually has: the field nobody fills in, the same supplier spelled three ways, the price that lives in one person's memory, the document misprinted years ago whose correct value exists only in the heads of long-serving staff. A cleaned extract launders exactly those defects out of the test, and the defects are where deployments fail.

The second function of this rule is what makes it non-negotiable. Asking for real data tests whether the customer will actually give you access. A customer who will not hand over a real slice for a two-week test will not hand it over at go-live either, and the refusal is information about the project rather than an obstacle to route around.

Rule two: shrink the coverage, not the depth

Under time pressure the instinct is to cut depth, because depth is invisible on a slide. Do the opposite. Cut how many sites, document types, roles, languages, integrations and exception classes appear in the first version. Keep the path end to end for the case you kept, keep a failure that can be seen, keep the one number that matters.

A recorded education group shows what full coverage buys. A team built the whole chain: intelligence gathering, data cleaning, report generation. It went unused. A principal in his sixties, with no engineering background, assembled a template-only agent in three days, and people used that instead. The chain covered more and was worth less, because the value sat in one step, the skeleton of the report, and the other steps were work the school already did well.

The opposite error breaks the same rule from the other side. Width without depth leaves nobody a single thing to rule on. A community account describes a large state-owned enterprise that contracted ten agents on a six-month plan; nearly a year later there was still no acceptance.

Cut: coverage	Keep: depth
Number of sites, departments or teams in scope	One complete path from input to a used output
Document types, languages, currencies	The top-priority metric from the metric table
Integrations beyond the one the flow depends on	A visible failure path: logs, tracing, an error a user can read
Exception classes, moved to a written known-unknowns list	The customer's right to reject the result at no cost

Rule three: the deadline is not negotiable

A fixed date is the only mechanism that turns "this would be better" into "this is dropped". Without one, an MVD decays into what it was meant to replace: an open-ended trial with no metric and no judge, which is how a pilot spends a year and ends without a verdict.

Set the date first, then decide what leaves. Recorded cycles are counted in weeks, not quarters: a five-day format used by one vendor, four weeks at the fastest for another, four to eight weeks for a third. The five-day version is the useful extreme, because it makes the trade-off explicit. Day zero picks one narrow battlefield; day one connects systems and pulls data; two days are build time with the customer's engineers sitting alongside; the last two put the result in front of executives who click it themselves. The buying decision happens in the same room as the evidence, which removes the gap where a demo usually stands in for proof.

When the date arrives and something is half-built, the honest move is not to extend. It is to move the unfinished piece out of scope, in writing, and ship the path that does not depend on it. That is a scoping decision. Extending is a debt with interest.

What it is not

Not a proof of concept, which answers whether something can be done at all, a question that stopped being interesting. Not a demo, which is built to be liked and therefore hides the two things you need to see: where the data breaks, and which step people quietly skip. Not an open-ended pilot, which has no exit by definition and no one whose job it is to say stop.

The check before you start

Answer three questions in writing: whose data, which number, what date. Then ask one after: did the person who will use it, use it themselves, with nobody standing behind them? If any of the four has no name attached, you are running an MVP with a deployment's vocabulary, and the first-week prototype conditions together with the four-week rule are what will eventually tell you so.