Ship the version
that teaches you something.
A specification tells you what people said they wanted. A working product tells you what they do. We build the smallest version real users can actually use, in production in days rather than quarters.
In — v1
Out — deliberately
Quick answer
What is a minimum viable product?
A minimum viable product is the smallest working version of a product that real users can use to accomplish a real task, released in order to learn what they actually do rather than what they said they would. The word minimum refers to scope rather than to quality: the feature set is deliberately narrow, while the engineering underneath — access control, data structure, server-side rendering, accessibility — meets the same standard as any production system, because these are the elements that cannot be retrofitted cheaply. The purpose is to replace assumption with evidence early, when changing direction still costs days. A prototype nobody can use produces opinions; a product in production produces behaviour.
Most MVPs fail before
anyone gets to use them.
The idea is rarely wrong. The path to testing it is.
Failure 01
The nine-month specification
Requirements are gathered until nobody disagrees, then built. The assumptions were never tested against a real user because there was nothing for them to use.
Failure 02
The prototype that became production
It worked in the demo so it shipped. No tests, no locked dependencies, no environment separation. The fourth feature never lands.
Failure 03
Minimum that is not viable
The scope was cut until nobody could complete a task. Users cannot use it, so it teaches nothing, and the conclusion drawn is about the market rather than the build.
Four deliverables, not a feature list.
Narrow scope, full engineering discipline. The two are not traded against each other.
01
Scope definition
The one thing version one must let a user do, and an explicit written list of everything it deliberately will not. The second list is the deliverable.
02
A production system, narrowly scoped
Server-rendered, access-controlled, accessible and typed, with dependencies locked and environments separated. Narrow, not provisional.
03
Deployment and gates
Live infrastructure in accounts you own, with verification gates on rendering, performance, accessibility and access control before anything reaches production.
04
Evidence loop
Instrumentation showing what users actually do, so the second thing you build is chosen from behaviour rather than from the original assumption.
Five steps, in this
order, every time.
Speed comes from not rebuilding what already exists, not from skipping what matters.
-
1
Frame
Define the single task version one must support, and write down what it will not do.
-
2
Model
Data structure, roles and access policies first. Default-deny applied before an interface exists.
-
3
Build
Server-rendered, typed, accessible, dependencies locked. Structured data written with the content.
-
4
Gate
Rendering, Core Web Vitals, accessibility, dependency audit and cross-tenant access verified before deploy.
-
5
Learn
Ship, observe real usage, then choose the second thing from evidence rather than from the plan.
Engineering rules in the Standard, each with a verification method.
Classified Critical: verified restorable backups and server-rendered discoverable content.
Pixel width at which every interface must remain fully usable.
Why scope is cut and engineering is not.
The temptation in fast delivery is to reduce both — fewer features and lighter engineering. The second is a false economy, because access control, data structure, rendering strategy and dependency hygiene are the elements that cannot be added cheaply afterwards. Retrofitting default-deny access policies onto a live system with real users is a migration; including them at the start is a design decision. The Standard therefore applies identically to a first version and a mature product. What changes between them is how much the product does, never how well it is built.
Source: The Qawex Standard v1.0, rules ENG-01 to ENG-11 · /standard/engineering/Answers, not brochures.
How can you build in days without cutting corners?
By not rebuilding what already exists. Authentication, the data layer, access policies, deployment and the component system are proven foundations we do not reinvent for each client. The days go into the part that is genuinely yours, and the checks that usually get skipped run automatically in the pipeline where they cost minutes rather than a decision.
What if we need something the MVP does not include?
You build it second, having learned whether it is still the right thing. The out-of-scope list is written down precisely so this conversation is explicit rather than a disagreement later. Version two is cheaper than version one because the foundations are already correct.
Is the MVP throwaway code?
No. It is a narrow production system, not a prototype, and it is built to be extended rather than replaced. Where a genuine throwaway prototype is the right choice — testing a single interaction, for example — we will say so, but that is a different and much smaller piece of work.
Who owns the code and the infrastructure?
You do. Code is delivered to your repository, infrastructure runs in accounts you own and pay the provider for directly, and there is no licence that expires or hosting arrangement that holds the system hostage. If you continue elsewhere, everything needed goes with you.
What happens after launch?
Either you take it from there with full access and documentation, or you move onto a managed package covering uptime, patching and optionally continuous re-audit against the Standard. Both are optional and neither locks the system to us.
Define the version worth building.
Scoping produces the in-list, the out-list and a realistic timeline before any commitment.