The phrase has been in use for fifteen years and quietly lost its meaning. Here is what Eric Ries actually wrote — and what it should mean for a solo SaaS founder in 2026.
Research-based overview. This piece draws on Eric Ries' original writing, public Indie Hackers interviews, and founder essays. How we research.
That sentence comes from page 77 of The Lean Startup, published in 2011 by Eric Ries. The book defines an MVP as a learning instrument, not a launch tactic. It is closer in spirit to a science experiment than to a product release. You decide what you want to learn, you build the smallest thing that will teach you, and then you decide what to do next based on the answer.
Fifteen years later the phrase “MVP” has been ground into mush. Founders use it to mean “the first version of the product I am ambitiously trying to ship.” Agencies use it to mean “a six-figure six-month build.” Investors use it to mean “something I can play with in a demo.” All three usages have wandered far from what Ries actually wrote.
Three things conspired. First, the word product in “minimum viable product” sounds like it implies code, design, and a polished user experience. Second, software got cheaper to build, so the floor of what counts as “minimum” rose with it. Third, MVP became a respectable shorthand to put on a roadmap, which means founders started using it to describe their plans rather than their experiments.
Most products called MVPs in 2026 are way over-built relative to the original definition. They have a custom design system, an authentication flow, a settings page, billing integration, and a marketing site. They take three to six months to ship. They cost $30,000 to $80,000 in agency time or 800 hours of founder evenings. And then they launch and find out the same thing a Notion form would have told them in a weekend.
Ries' original test was simpler: does this teach me what I need to know to make the next decision? If a single landing page with a Stripe checkout link teaches you whether anyone will pay, that is an MVP. If a Calendly link to book a paid 30-minute call teaches you whether the problem is real, that is an MVP. The build does not need to be a product in the conventional sense. It needs to be a viable instrument for learning.
For a solo founder with limited time and capital, the bar for “minimum” should be unreasonably low. Here are five formats that all count as legitimate SaaS MVPs in 2026, ranked roughly by build effort:
| MVP format | What it tests | Build effort |
|---|---|---|
| Landing page + waitlist | Whether the headline resonates and people will leave an email | 2–4 hours |
| Landing page + Stripe checkout | Whether anyone will pay before the product exists | 4–8 hours |
| Notion form + manual fulfillment | Whether the workflow is valuable when you do it by hand | 1 day |
| Gumroad page selling a one-off | Whether a transactional version of the SaaS sells before recurring | 1 day |
| Concierge SaaS with one customer | Whether one paying customer is enough to learn the shape of the product | 1–2 weeks |
Notice what is missing from all five: a database schema, a login screen, a settings page, a tier picker, password reset emails, a 404 page, GDPR cookie banners, and Terms of Service. Those things become necessary later. They contribute zero learning before you have your first paying customer.
Our walkthrough on how to validate a SaaS idea in 48 hours uses three of these formats end to end — landing page, fake checkout, and concierge fulfillment — and shows what each is good for at different stages of belief.
Solo founders kill more weekends to these five anti-patterns than any others. They feel productive. They are not.
Auth is not a feature. It is a tax you pay to charge multiple users. Until you have a single paying user, you do not need user accounts — you can run the entire MVP as a manual workflow against a Stripe checkout link and a shared inbox. Founders routinely spend the first weekend on Clerk or Auth0 integration and learn nothing about whether the product is wanted.
Tailwind UI, shadcn/ui, or even raw default browser styles are sufficient for an MVP. Custom typography choices, color palettes, and component libraries are signals that you are designing a brand instead of testing a hypothesis. This is the most common evening time-sink for founders coming from a design background.
Sending email is a solved problem. Resend, Postmark, and Loops have generous free tiers and ship in under an hour. Building your own templating engine, logging system, and bounce-handling logic is real work that adds zero learning. If you do not have a paying customer, your email volume is single digits per week and a personal Gmail draft is sufficient.
One price. One plan. Pre-product-market-fit, multi-tier pricing exists to make founders feel like real businesses. It also splits the data in your funnel so finely that you cannot tell whether your conversion rate is a real signal or noise. Once you know what a customer is worth and how often they upgrade, then you can split. Our solo founder pricing playbook covers when and how to add tiers without losing signal.
If you are pre-MVP and you are reading documentation about i18n libraries, close the tab. Ship in English, take USD via Stripe, and worry about other currencies and languages after $5k MRR. There has never been a SaaS that died because it lacked French support at launch. There have been thousands that died because the founder shipped slowly enough to have time to think about it.
The clearest evidence that MVPs in the original sense still work comes from the public archives of Indie Hackers and the build-in-public side of Twitter/X. Two examples that are well documented:
In 2014, Pieter Levels published Nomad List as a public Google Sheet. Cities in rows, attributes in columns, sortable. It went viral on Hacker News. Only after thousands of people had already shown they cared did Levels rebuild it as a real web product. He has documented the exact sequence in interviews and on his site at levels.io. The product hit roughly $50k MRR within two years and continues to operate as a one-person business.
Tony Dinh shipped the first version of DevUtils — a native macOS developer-utilities app — as a single binary with two utilities and a paid download via Gumroad. No login, no user accounts, no SaaS infrastructure. Sales told him which utilities to add next. He has chronicled the journey publicly on his blog at tonydinh.com and the product reached $40k+ MRR with a single founder.
Both founders started with something embarrassingly small that taught them something specific. Both treated their first “product” as a hypothesis test, not a launch. Both ended up with seven-figure annual revenue.
You can find more patterns like this in our roundup of micro-SaaS examples, which profiles a dozen solo-founder products and traces what their actual MVP looked like before the polished version they have today.
The hardest decision in the MVP phase is knowing when it is time to stop running it as a learning instrument and start building it as a real product. Three signals tend to appear together when it is time to make that shift.
Signal one: you are spending more time on manual fulfillment than on shipping. If your concierge MVP is taking five hours a day to operate, the bottleneck has moved from learning to scaling. Automate the most repeated step.
Signal two: customers are asking the same question twice. The first time a customer asks for a feature, ignore it. The third or fifth time, that feature is now part of the product. The transition from MVP to product begins when you start saying yes to repeated requests instead of saying “I'm still validating.”
Signal three: you can describe your customer in one sentence. An MVP succeeds when you discover who your real buyer is — not the imagined buyer in your launch deck, but the actual person who keeps paying. Once you can name them, the product can be designed for them. Our framing on what product-market fit actually means covers this transition in detail.
When all three signals appear, the MVP has done its job. It taught you what to build. Now you can stop running experiments and start compounding. The zero-to-$1k MRR playbook picks up exactly here: how to take a working MVP and turn it into the first thousand dollars of recurring revenue.
An MVP is not a small version of your product. It is the smallest thing that will teach you whether your product should exist at all. If you find yourself shipping auth before you have a paying customer, building a design system before you have a logo, or planning a tier structure before you have a single subscriber, you have already wandered off the path Eric Ries laid out. Come back. Ship something embarrassingly small. Listen to what it teaches you. Then build the next thing.
The stack, prompts, pricing, and mistakes to avoid — for solo founders building with AI.