Reading minimum viable product examples for startups can mislead you, because the famous stories skip the part that matters for your budget. Atlassian's guide to the minimum viable product lists Amazon as an online bookstore, Uber as an SMS-based cab service and Spotify as a simple landing page. Those summaries are accurate but thin. They rarely show which parts were built and which were done by hand, and that difference decides what you pay for.
The best minimum viable product examples for startups each tested a single assumption before anything else. Nielsen Norman Group describes an MVP as the simplest version of a product, and the key word is simplest, not smallest. A product can be tiny and still test the wrong thing. A founder who builds ten modest features has not made an MVP, only a slow launch.
Gagan Biyani, who co-founded Maven and Sprig, makes a sharper point in First Round Review's piece on minimum viable testing. He argues that an MVP is often not small, since it can need a login system, a database and an admin dashboard. His answer is to test the riskiest assumption first and build the product afterwards. You may not follow him all the way, but the logic helps when you set a budget.
In a Hacker News thread on MVP examples, one commenter says CD Baby began with links to buy albums while the founder filled orders by hand. Another says Zappos began as pictures of shoes with prices, and staff bought the shoes from a store when someone ordered. These are recollections from commenters, not audited histories, so treat them as illustrations. Still, the mechanism holds: a manual back office costs hours, while automated fulfilment costs real development budget.
A consultant in the same thread states the rule plainly: do not automate a process until it actually takes up your time. His warning is that people build bespoke software for workflows that do not yet exist in their business. The real bottlenecks, he writes, usually sit somewhere else.
Another commenter recalls that the first iPhone shipped without copy and paste, yet stayed recognisable as an iPhone. Others note that Yahoo began as the founders' personal list of links, without categories, and that Launchrock launched with a launch page. Each cut everything except the one thing users came for. Cutting is harder than building, because every omitted feature feels like a risk to someone on the team.
Biyani's Sprig story is the clearest case. To test whether meal delivery operations could work, the team used a private chef found on Craigslist, took orders through Eventbrite and tracked drivers with pieces on a map. By his account, they delivered more than 40 meals in one night after two weeks of preparation, with no app. At Maven, he reports that a single co-taught course earned over $150,000 in its first cohort with a 9/10 student rating, and the team built no course software for it.
Biyani also reports running three tests over six months at Sprig, and five over nine months at Maven, before shipping a product. Those are his figures for his own companies, and your timeline will differ. What carries over is the order of work: name the risk, test it cheaply, then build.
Copying a famous feature list does not work, but copying the decision process does. For each part of your product, ask three questions: does the test fail without it, can a person do it by hand for now, and can it wait? The table below shows how that sorting often looks.
| Part of the product | Build it when | Do it by hand when | Leave it out when |
|---|---|---|---|
| Ordering or sign-up | Users cannot reach the offer without it | Order volume is low enough for a form or email | A landing page and waiting list can test interest |
| Fulfilment | Manual handling would distort the result | A person can deliver each order and you learn the real effort | You are still testing whether anyone wants it |
| Accounts and logins | Each user's data must stay private | Access can run through invite links | Nobody returns before the core value is proven |
| Admin tools | Several people run operations daily | Spreadsheets cover your own team | You are the only operator |
| Reporting | It answers the question your test asks | A weekly manual summary is enough | It only decorates the product |
Martin Fowler's site describes an MVP canvas from the Lean Inception workshop that enforces this discipline. It asks seven questions, and features come fourth, although most founders start there.
Survivorship bias is the first problem. Even good minimum viable product examples for startups are chosen because the company grew, and they say nothing about the launches that tested an idea and stopped. Biyani offers a counter-case himself: a travel advice idea he dropped after one test showed that matching advisors to customers was harder than expected. A test that ends in a stop still succeeds if it saved you the build.
A good MVP is a question you pay to answer, not a smaller version of the answer.
Definitions also differ. One Hacker News commenter argues an MVP is the smallest thing people would use, paying or not, while another says it should be something you can charge for and feel proud of. Neither view is wrong. Your choice depends on whether you are testing demand or testing quality, so decide which before you scope anything.
If you want to see what a scoped first release costs, our guide to custom MVP development cost breaks down the main drivers. For a fixed budget tied to a defined scope, Xerx fixed-price MVP development is one route, but any studio should agree the scope in writing first. Our customized business software examples show what custom builds look like once the first release has done its job.
Biyani's Sprig and Maven tests suit you well, because a private chef and a single co-taught course needed no software. The CD Baby and Zappos stories, as Hacker News commenters tell them, also relied on manual fulfilment.
No. Biyani's tests used a hand-dispatched dinner service and one course. The test only has to answer your riskiest question, and software is one possible means.
No fixed number applies. Fowler's MVP canvas places the feature list after the proposal, personas and journeys, then trims it to the minimum viable. Keep what your expected result requires.
Opinions differ. In the Hacker News thread, one commenter says it counts only if you are in the landing page business, and another calls it closer to a demand test. It can still serve as a cheap first signal.
Keep reading
Stop burning cash on hype. Learn how to evaluate technical partners, control integration costs, and build automated workflows that actually drive commercial value.
Looking for a reliable AI MVP development strategy? Discover how founders can avoid hype, control costs, and build automation that actually delivers ROI.
Discover how founders can successfully scope an AI automation project by focusing on measurable business bottlenecks, total cost of ownership, and maintainable architecture over fragile hype.
