MVP vs V1: what to build first so you don't waste three months

A founder came to me last year, exhausted and nearly out of money. He'd spent about four months and most of his savings building what he proudly called his "MVP" — a SaaS tool for managing small tuition centres. Attendance, fees, timetables, a parent app, a teacher app, WhatsApp reminders, reports, a website builder for the centre, even a little AI chatbot. It was genuinely impressive. It was also almost dead on arrival, because in four months of building he had spoken to exactly two tuition centres, and neither had asked for most of what he built.

Here's the part that still stings. When we looked at what the two centres actually cared about, it was one thing: collecting monthly fees without the awkward chasing. Everything else was noise. He could have tested that one thing in two weeks, learned that fee collection was the real hook, and built from there. Instead he built a V1's worth of features, called it an MVP because it wasn't "finished," and ran out of runway before finding out which parts mattered.

This is the most expensive misunderstanding in software, and it has a simple name: confusing an MVP with a V1. They sound similar. They are opposites in spirit. One is built to learn with the least effort. The other is built to be relied on every day. Mix them up and you spend three or four months and a lot of money buying an answer you could have bought in two weeks.

This post is the conversation I wish every first-time founder had before they wrote a single line — or paid anyone to. I'll explain what an MVP actually is, how it differs from a V1, why building the wrong thing is the number one killer of startups, and then I'll give you a concrete cut-list method to decide exactly what goes in the first build and what waits. There's a fully worked example at the end, taking one real idea from a bloated wish-list down to a two-week MVP. If you haven't even validated the idea yet, read how to validate a SaaS idea in a weekend first — this post picks up right after that.

What an MVP actually is (and the two words everyone drops)

The term "minimum viable product" was coined back in 2001 by Frank Robinson, a product-development consultant, and made famous by Steve Blank and Eric Ries. In his book The Lean Startup, Ries defined it precisely: the MVP is "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort."

Read that again, because two words in it get quietly dropped by almost everyone who uses "MVP" in a meeting. The first is learning. An MVP exists to teach you something you don't yet know — usually "do the right people actually want this, and will they use it and pay for it?" It is a question, built in software. The second is least effort. Not "small version of everything." Not "the product but rougher." The least you can build to get a trustworthy answer.

When founders forget those two words, "MVP" comes to mean "the first version of my product, but I ran out of time so it's a bit rough." That's not an MVP. That's an unfinished V1. And unfinished V1s are where startups go to quietly die, because you've taken on all the cost and risk of building without buying any of the learning that was supposed to justify it.

The honest way to hold it in your head: an MVP is an experiment. A V1 is a promise. An experiment can be manual, ugly, and half-fake, because its only job is to produce a clear yes or no. A promise has to actually work, every day, for someone paying you — because you've now told the market "rely on this."

MVP vs V1: the real difference

Because this distinction is the whole game, here it is side by side. Keep this table in front of you when you scope your first build.

Notice the last row. The entire reason to do an MVP first is that the cost of being wrong is small. You are buying insurance against the most common and most fatal startup mistake — building something nobody wants — and the premium is a couple of weeks instead of a couple of quarters.

Why building the wrong thing is the #1 way startups die

I'm not being dramatic when I call this the top killer. There's solid data behind it.

CB Insights, a research firm, read through 101 startup post-mortems — founders writing honestly about why their company died. The single most common reason, named in 42% of failures, was "no market need" — they built something the market didn't want. It beat the next reason, running out of cash (29%), by a wide margin. And the two are linked: you rarely run out of money building the right thing, because the right thing attracts customers and revenue. You run out of money building the wrong thing, slowly, in the dark.

There's a second, older piece of research that every founder should sit with. In a 2002 keynote, Jim Johnson of the Standish Group shared a study of how often software features actually get used. The result: 45% of features were never used at all, another 19% rarely — and only about 20% were used often or always. It was a small study, and people have argued about the exact numbers for twenty years, but the direction has been confirmed again and again since: most of what teams build barely gets touched. We are, as builders, terrible at guessing which features matter.

Put those two findings together and the message is blunt. You will probably build the wrong things, and building the wrong things is what kills companies. The MVP is simply the cheapest way to be wrong. Every feature you don't build in the first version is money you keep, time you keep, and one more thing that can't break, confuse users, or hide the signal you're trying to read.

The cheapest MVPs have no code at all

Before we get to cutting features, sit with an uncomfortable idea: the best first MVP for your idea might have no software in it whatsoever. Code is one of the slowest, most expensive ways to answer a question. Often there's a faster one.

Here are the four cheapest kinds of MVP, roughly in order of how little you build:

• The landing page. A single page that explains the product as if it exists, with one button — "Get early access" or "Notify me." You count how many of the right people click and sign up. It tests demand and messaging before you build anything.
• The demo video. You show the product working, even if it doesn't yet. This is exactly what Drew Houston did for Dropbox: he posted a short screencast demonstrating file-syncing before the product was really built. Dropbox's beta waitlist reportedly jumped from about 5,000 to 75,000 people overnight — proof of demand, bought with a few hours of screen recording.
• The concierge MVP. You deliver the outcome by hand for your first few customers, behind a simple form or a WhatsApp number. No automation, no dashboard — just you, doing the work manually, learning exactly what customers need before you teach a machine to do it.
• The "Wizard of Oz" MVP. The customer sees a working product; behind the curtain, humans are doing what looks automated. Zappos began this way — founder Nick Swinmurn photographed shoes at local stores, put them online, and when someone ordered, went and bought the pair and shipped it. He tested "will people buy shoes online?" without owning a single box of inventory.

The point isn't that you should never write code. It's that you should write code to scale something you've already proven people want by hand — not to discover whether they want it. The concierge and Wizard-of-Oz approaches are especially powerful for Indian small-business SaaS, because you learn the real workflow (and the real objections) from actual customers before you spend on building.

The cut-list method: deciding what goes in the first build

Say you've validated demand and you genuinely do need to build software. Now comes the hard part: choosing what goes in the first version and what waits. Most founders do this by feel, and by feel, everything feels essential. Here's a method that forces honest choices. I use some version of this on every project.

Step 1 — Write the one job, in one sentence

Finish this sentence with no "and" in it: "This product helps [one type of person] do [one important thing]." Not three types of person. Not five things. One and one.

The tuition founder's real sentence turned out to be: "This product helps a small tuition-centre owner collect monthly fees without chasing parents." That's it. Every "and" you're tempted to add — "and attendance, and a parent app, and reports" — is a future version, not this one. If you can't say the job in one clean sentence, you don't yet understand the customer well enough to build. Go back and talk to more of them.

Step 2 — Brain-dump every feature, with no judgement

Now empty your head. Write down every single feature, screen, and idea you have for the product — the whole dream. Don't filter yet; you want it all out where you can see it. Most founders land on somewhere between 20 and 50 items. This messy list is your raw material.

Step 3 — Force each feature into a bucket (MoSCoW)

Take each item and drop it into one of four buckets. This is the MoSCoW method, created by Dai Clegg in 1994 and used in serious software delivery ever since. The buckets:

• Must have — the product is pointless without it. Remove it and the one job from Step 1 no longer gets done.
• Should have — genuinely important, but the product still delivers the core outcome without it for now.
• Could have — nice. Adds polish or covers an edge case. Nobody churns without it.
• Won't have (this time) — explicitly parked. Not rejected forever; just not now.

The discipline is in being ruthless with "Must." A feature is only a Must if the very first customer cannot get the core outcome without it. Payment collection is a Must for a fee-chasing tool. A dark-mode setting is not. A dashboard with ten charts is almost never a Must — one number the owner cares about usually is.

If you find that nearly everything is landing in "Must," that's not thoroughness — it's a red flag. It almost always means you're secretly trying to serve several different customers at once. Narrow the Step 1 sentence to one customer, and watch two-thirds of the "Musts" quietly become "Shoulds."

Step 4 — Run the "one user, one problem, one action" test

For each remaining Must, ask three questions:

1. Does this serve the one user from Step 1, or a different user I'm sneaking in?
2. Does it solve the one problem, or a related-but-separate problem?
3. Can the user complete the one core action without it?

If a feature fails any of these, it drops out of the MVP. A parent-facing app, for the tuition tool, fails the first test — it serves parents, not the owner. A reports section fails the third — the owner can collect fees without it. Out they go, into "Should" or "Could." What survives is a genuinely minimal build.

Step 5 — Draw the line, and set the three-month rule

Now draw a hard line under the "Must" bucket. Everything above the line is your MVP. Everything below is your roadmap — and having it written down is a gift, because you'll stop worrying you've "forgotten" things. You haven't; you've scheduled them.

Then apply the three-month rule as a safety check: if building only the Must-haves will still take more than about three months, your MVP is too big. Something in the "Must" bucket is really a "Should," or the one job is still too broad. Cut again. It is almost always better to ship a smaller thing in six weeks and learn, than a bigger thing in six months and hope.

A fully worked example: from wish-list to two-week MVP

Let me make this concrete with a fresh example — a made-up but realistic one, so you see the method run end to end. Say you want to build a SaaS tool for home bakers in India who sell cakes over Instagram and WhatsApp. Here's the full journey.

Step 1 — the one job. After talking to a dozen bakers, the sharpest pain isn't marketing or payments — it's order chaos. Orders come in over WhatsApp DMs, comments, and calls, and bakers lose track of who ordered what, for when, with which customisations. So the one sentence becomes: "This product helps a home baker keep every order in one place so nothing gets missed or muddled."

Step 2 — the brain-dump. The dream list comes out to about 24 items: order intake form, order calendar, customer list, automatic WhatsApp confirmations, payment collection with UPI, deposit/advance tracking, recipe costing, ingredient inventory, a public storefront page, reviews, a loyalty program, delivery-partner integration, GST invoices, analytics dashboard, staff logins, and more.

Step 3 — MoSCoW. Sorting honestly against the one job:

Step 4 — the three tests. The advance-payment tracking is tempting to call a Must — but a baker can keep orders straight without it (they can note payments manually for now), so it fails the "core action without it" test and stays a Should. The storefront page serves buyers, not the baker, so it fails the "one user" test — it's a Could at best. What survives as the MVP is tiny: a form to capture an order, and one clean view of all upcoming orders. That's the whole first build.

Step 5 — the line and the clock. That MVP is genuinely buildable in about two weeks with today's no-code and AI-assisted tools — well under the three-month rule. Everything else is now a written roadmap, not a worry. You put it in front of ten real bakers, and you watch. Do they actually enter their orders? Do they open it the next morning? Do they stop losing orders? That is the learning the whole exercise was for. If they use it daily, you've earned the right to build the "Should" bucket and turn this experiment into a real V1. If they don't, you've spent two weeks, not four months, finding out — and you can pivot to whatever they do keep asking for.

That's the entire difference between the tuition founder's story and a healthy one. Same energy, same ambition. A completely different order of operations.

When a bare-bones MVP is the wrong call

I'd be lying if I said "always build the smallest thing" with no exceptions. There are real cases where a too-minimal MVP hurts you, and honesty about them is what separates advice from hype.

When trust is the whole product. If you're handling people's money, health records, or sensitive customer data, a janky MVP can do lasting damage — people don't forgive a payments tool that loses a transaction. Here, "viable" has to include being trustworthy for the core action, even if everything around it is bare.

When you're the tenth entrant, not the first. If you're launching into a crowded category where customers already have polished options, a rough MVP may just look worse than what they use today. You still start minimal, but "minimal" has to clear a higher bar to earn a switch — usually by being dramatically better at one specific thing.

When the manual version can't teach you the automated one. Some products only reveal their real challenges at scale or in code. But this is rarer than founders think — most of the time a concierge MVP teaches you more, not less, because you feel every rough edge yourself.

Even in these cases, the principle holds: reduce the biggest risk first. If your biggest risk is "can we build this reliably?", then a small, solid technical slice is your MVP. If your biggest risk is "does anyone want this?" — and for most first-time founders, it is — then a landing page or a concierge test beats months of building every time. Match the MVP to the scariest unknown.

Build the first version cheap — that's the point

One last India-specific reality. The whole logic of MVP-first only works if the first build is genuinely cheap and fast. If your MVP itself costs ₹3–4 lakh and four months, you've lost the plot — you're back to betting big before you've learned anything.

This is where the tools have changed everything in the last two years. No-code platforms and AI-assisted development mean a genuinely minimal product — one form, one clean view, one core action — can be built in weeks for a fraction of what it cost even three years ago. That's not a reason to build a bigger MVP; it's a reason to keep it small and keep it cheap, so being wrong costs you almost nothing. If you're weighing how to build it, no-code vs custom for your first version walks through the honest trade-offs by business type. For most MVPs, no-code or AI-assisted is exactly right — you can always rebuild the parts that matter properly once you know which parts matter.

And resist the urge to gold-plate. The instinct to make the MVP "just a bit nicer" before showing anyone is the same instinct that turned four founders I know into unfinished-V1 casualties. Rough is fine. Rough is the point. You are not shipping a promise yet; you are asking a question. Ask it fast, ask it cheap, and let real customers — not your fears — tell you what to build next.

The whole method on one page

If you take nothing else, take this checklist:

1. Decide what you're building: experiment or promise. MVP = learn cheaply. V1 = serve reliably. Never confuse them.
2. Reduce the scariest risk first. Usually it's "does anyone want this?" — so test demand before you build the machine.
3. Try the no-code MVPs first: landing page, demo video, concierge, Wizard of Oz. Code only to scale what's already proven.
4. Write the one job — one user, one problem — in a sentence with no "and."
5. Brain-dump every feature, then force each into Must / Should / Could / Won't. Only "Must" ships.
6. Run the one-user, one-problem, one-action test on every Must, and cut what fails.
7. Apply the three-month rule: if the Musts still take longer than that, cut again.
8. Ship, watch real behaviour, and graduate to a V1 only when people retain and pay.

The founders who win aren't the ones who build the most. They're the ones who learn the fastest, for the least. A good MVP isn't a smaller product — it's a sharper question. Ask it well, and the market will tell you exactly what to build next. If you'd like a hand scoping that first minimal build so it stays genuinely minimal — and cheap — that's exactly the kind of thing we do at the Studio. But whether you build it with us or not: build the question first, not the whole answer.