MVP Development
An idea becomes a small working product, scoped around the one question your business needs answered before it commits the budget for the whole thing.
You have an idea, a rough sense of what it might be worth, and no evidence. The budget to find out is smaller than the budget to build it, and the people who control the larger one want something to look at first. What settles it is whatever piece of working software puts the riskiest assumption in front of real users soonest.
Most MVPs answer nothing in particular.
The cut-down product
A thinner version of the full product, shipped fast to see what happens. It is cheap to start and easy to explain to a board.
- Scope is whatever fits the budget and the calendar
- Every feature is present, each one thinner than intended
- Done means shipped, so success is hard to read
- Useful when the market is proven and the build is the risk
Scoped around one question
Name the assumption the business cannot afford to be wrong about, then build only what is needed to test it. The answer is the deliverable.
- One user journey built properly, everything around it left out
- The result that would kill the idea, agreed in advance
- Manual work behind the screen wherever a human is cheaper
- Ends in a decision: continue, change direction, or stop
Cut breadth, not the thing being tested
An MVP usually fails because the smallness was spread evenly, so every screen was half-built and the one journey you needed to observe was as broken as the rest. Cut breadth instead. One path through the product gets the real treatment: the error states, the empty states, the loading that takes too long, the message that tells someone what went wrong. Everything beside it is left out.
Two things make that possible. Behind the screen, a person can do by hand what a system would otherwise do badly, and at the volume an early test produces, nobody notices. Most of what makes software hard is only hard at scale: the sharding, the admin console for a support team you have not hired. Defer all of it on purpose, and write down that you did.
The build starts after the question does
Phases, not dates. Each one ends with something you can look at and a decision you can take, including the decision to stop.
- 01Phase 1
The question
We write down what you believe, what would have to be true for it to work, and which of those beliefs is both uncertain and expensive to be wrong about. That last one is what the build tests. Everything else waits.
- 02Phase 2
The thinnest path
One journey, drawn end to end, with the manual steps marked as manual. You see the screens before they are built, and you agree what a user has to do for the test to count as a real attempt.
- 03Phase 3
Build and release
Built in your repositories and your cloud accounts, released in slices rather than held back for a launch. Instrumentation goes in with the first slice, because an MVP with no measurement produces opinions instead of an answer.
- 04Phase 4
The verdict
Real users, watched rather than surveyed. Then a written read of what happened against the threshold you set in the first phase, the decisions that were made and why, and a straight recommendation: build it properly, change the question, or stop.
What you get
The software is the visible part. The reason to run this as an engagement rather than a hackathon is what comes with it, and what you keep when it ends.
One journey built for real
A working path a stranger can complete without you sitting beside them, which is the only version that produces evidence worth anything.
Measurement fitted before launch
The events that answer the question, instrumented as the feature is built rather than added afterwards when the interesting week has already gone.
Code you own from the first commit
Your repositories, your cloud accounts, a conventional stack. If the answer is yes and you want to continue with your own team, nothing has to be handed over.
A written record of the shortcuts
Every deferred piece listed with the reason it was deferred, so a later team knows what was a decision and what was a corner cut under time pressure.
The awkward questions
It stays where it already is, in your repositories, and some of it gets rebuilt. The parts that carried real users tend to survive; the manual steps and the shortcuts we listed have to be replaced before the system can take load. Treat the MVP as evidence that happens to run, not as a foundation you have already paid for.
Not sure which one you need?
Describe the problem in a paragraph and we will tell you which service applies.