MVP Examples That Teach Scope Discipline
Well-known MVP stories and the patterns behind them, for shipping the smallest useful version.
"Minimum viable product" has been stretched to mean almost anything: a prototype, a first release, a product with half its features missing. The original idea, popularised by Eric Ries in The Lean Startup, is narrower and more useful. An MVP is the smallest thing you can put in front of real people to test your riskiest assumption.
The word that does the work is "assumption". An MVP is not a small product. It is an experiment that happens to look like a product. That framing is what makes scope discipline possible: once you know which assumption you are testing, you can cut everything that does not test it.
Below are a handful of widely told MVP stories, what each one actually tested, and how the same pattern looks for small-business software. Where an example is invented to illustrate a point, it is labelled as hypothetical.
Five well-known stories and what they tested
These are commonly retold in startup books and talks. The details are simplified here; the lesson in each is what matters.
Zappos: will people buy shoes online? Founder Nick Swinmurn is said to have photographed shoes in local shops and posted them on a simple website. When someone ordered, he bought the pair at retail and shipped it. There was no inventory, no warehouse and no logistics system. The assumption being tested was demand, so demand was the only thing he built for.
Dropbox: do people want seamless file sync? Before the product was ready for the public, Drew Houston made a short screencast showing how it would work and shared it with a technical audience. The video drove sign-ups to a beta waiting list. The risk was whether people cared, and a video answered that far more cheaply than a finished sync engine.
Buffer: will anyone pay to schedule social posts? Joel Gascoigne has written about starting with a landing page describing the product. Clicking through led to a pricing page, and choosing a plan led to a note saying the product was not ready yet, with a box for an email address. It tested interest, then willingness to consider paying, before any code was written.
Airbnb: will strangers pay to stay in someone's home? The founders famously rented out air mattresses in their own San Francisco apartment when a conference had filled local hotels. The first version was a basic website and their own floor.
Groupon: will people act on a group deal? It reportedly began as a WordPress blog, with deal vouchers generated as PDFs and emailed by hand.
Notice what none of them did: build the full system first. Each picked the scariest unknown and built only enough to see it answered.
The patterns behind the stories
Strip away the famous names and you get a small set of reusable shapes.
| Pattern | What it tests | What you skip building | | --- | --- | --- | | Explainer video or demo | Does anyone care? | The product itself | | Landing page with a pricing step | Will they consider paying? | Everything behind the button | | Manual behind the scenes | Will they use it if it works? | Automation | | Concierge | What does the job actually involve? | Software, at first | | Single-feature product | Is this one job worth paying for? | Every adjacent feature | | Existing tools glued together | Does the workflow hold up? | Custom infrastructure |
The "manual behind the scenes" pattern is sometimes called Wizard of Oz: the customer sees an interface, but a person does the work out of sight. Concierge is similar, except the customer knows a person is doing it.
How it looks for small-business software (hypothetical examples)
The following are invented illustrations, not real companies.
A rostering tool for cafés. The riskiest assumption is not "can we build a roster screen". It is "will owners trust software to suggest shifts". A disciplined MVP: owners send next week's availability by form, the founder builds the roster in a spreadsheet, and emails it back as a clean PDF. If owners keep sending the form for a month, the demand is real. If they stop after week one, no amount of drag-and-drop would have saved it.
Job cards for a plumbing business. The founder suspects tradies hate paper job cards but will not switch to anything that needs a laptop. MVP: a single mobile form that captures the job, photos and a signature, and emails a PDF to the office. No scheduling, no invoicing, no customer database. It tests one thing: will they fill it in on site.
Client onboarding for bookkeepers. The assumption is that bookkeepers lose hours chasing documents from new clients. MVP: a shared checklist link per client, with the founder manually sending reminder emails each morning. If bookkeepers report saving time, automate the reminders next.
Booking deposits for a salon. The question is whether no-shows fall when clients pay a deposit. MVP: a booking page connected to an existing payment link, run for one salon for a month, with no-shows counted by hand.
In each case, the thing that feels like the product (the full scheduler, the dashboard, the settings page) is exactly what gets cut.
A scoping exercise you can do this afternoon
- Write your assumptions. List every belief the business depends on: people have this problem, they will switch, they will pay, they will use it weekly, you can reach them.
- Rank by risk. Which one, if wrong, kills the idea fastest? That is the one your MVP tests.
- Describe the smallest test. One sentence: "We will [do this] with [these people] and consider it a pass if [this happens]."
- Strike features. Go through your planned feature list and delete anything that does not help answer step three.
- Set a stop date. Two to six weeks is a reasonable rule of thumb for a first test. Decide in advance what result would make you change direction.
If step four leaves you with almost nothing, good. That is the point.
Mistakes that inflate an MVP
- Building for the second customer before the first. Multi-tenant permissions, white-labelling and admin panels are all real needs, eventually.
- Polishing to avoid feedback. Another week of design work is often a way of postponing the moment someone might say no.
- Testing the easy assumption. "Can we build it?" is rarely the real risk for a competent team. "Will a busy owner change their habit?" usually is.
- Measuring sign-ups instead of use. A waiting list proves curiosity. Repeat use proves value.
- Keeping the manual version too long. Concierge work is a test, not a business model. Once the answer is clear, automate the painful parts.
Putting a small MVP in front of real businesses
Scope discipline only pays off if the right people use the result. A tiny, focused product tested by the wrong audience tells you nothing.
LetsBeta is built for this stage. You list a build that is still in progress, a person reviews it before it goes live, and businesses in the relevant category apply to try it free. You choose whom to accept, and each accepted Early Adopter sends a mid-trial and end-of-trial report, including whether they would pay and what price seems fair. Your product stays on your own site; LetsBeta handles the matching and the structured feedback.
If you are not sure what to build at all, demand posts show what businesses say they need. For the next step after your first test, read Product-Market Fit Playbook and Beachhead Market.
What to remember
Every good MVP story is really a story about what the founders refused to build. Name your riskiest assumption, build only what tests it, and put it in front of people whose answer counts.