How to Build an MVP: Scope Version One in Weeks, Not Months

A practical way to build an MVP is to pick one narrow user with an urgent problem, give yourself a firm deadline of a few weeks, write down every feature you think you need, then cut every item a desperate user could live without. Ship what is left, watch whether it solves the problem, and iterate on a regular cadence.

Most first MVPs we see are too big. Not too ugly. Too big.

The founder who spends six months polishing version one usually learns less than the founder who ships something rough in three weeks and watches what happens. The rest of this guide is about holding the line when every conversation tempts you to add one more feature.

Definition: A minimum viable product (MVP) is the first, deliberately small version of a product you can put in front of real users to learn whether it solves their problem. Eric Ries, who popularized the term, frames it as the version that yields the most validated learning about customers for the least effort.

What an MVP is, and the three myths that slow founders down

We define an MVP as the first thing you can hand your first target users to see whether you deliver any value to them at all. It is a base to iterate from. It is not a product launch, a brand statement or the vision. If it feels slightly embarrassing, you may be close. Michael Seibel's shorthand is hard to improve on: "launch something bad, quickly."

Why hurry? Because most of the learning starts once a product is in front of users. Interviews tell you about the pain. Usage tells you whether your solution relieves it.

Three myths keep founders building for months instead of weeks:

1. Myth: early users who see a broken product won't come back. The people willing to try an unknown startup's product tend to be early adopters who are used to things that don't quite work. Many of the people who would flee at the first bug were unlikely to try you anyway.
2. Myth: great founders build the full vision first. Call it the fake Steve Jobs trap. The first iPhone had no App Store, no video recording and only 2G data. Even the canonical visionary shipped and iterated.
3. Myth: users will tell you what to build. Customers are experts in their problem, not in the solution. Their job is to describe the pain. Designing the fix is yours.

If you haven't yet confirmed that anyone has the problem, start one step earlier with how to validate a startup idea before you build and our customer interview playbook.

What famous version ones actually looked like

The gap between version one and the company you know today is, to us, one of the strongest arguments for shipping small:

What we take from that table: each was fast to build, each did very little, and each appealed to a small set of users. None tried to serve every future customer on day one.

Two well-documented MVPs from outside the usual software stories make the same point:

• Zappos. In a 2012 Fortune interview, founder Nick Swinmurn described offering a Sunnyvale shoe store a deal: he would photograph its shoes and post them online, and if anyone ordered he would buy the pair from the store at full price.
• Dropbox. TechCrunch's 2011 account of Dropbox's early growth reports that a demo video helped the company get into YC, and that a later version posted to Digg drove 75,000 waitlist signups in 24 hours when the team had expected about 15,000 at most.

Neither was a product yet. Both were tests. Look for the cheapest thing that tests your riskiest assumption, and consider shipping that.

How to build an MVP step by step: date, list, cut

One way to scope version one takes eight steps. The core is three moves (fix the date, list everything, cut hard), wrapped in a clear problem up front and a feedback loop at the end. Adapt them to your product and team.

Step 1: State the problem in one sentence

If you can't state the problem in a sentence or two, you may not know it well enough yet. And without a clear problem, it's hard to tell whether you solved it. Write the sentence down before any code and check that every founder agrees with it.

Step 2: Name the desperate first user

Build for someone in enough pain to accept an imperfect fix. If your hair is on fire and a brick is all that's for sale, you buy the brick. Your MVP is the brick. The comfortable users can wait.

Test the problem on two axes: how often the user hits it and how intense it is. Frequent, intense problems (like getting across town) tend to make good businesses. Rare, mild ones struggle to get anyone to talk to you, let alone pay. It's the difference we draw between a vitamin and a painkiller, and an MVP has a much easier life as a painkiller.

Step 3: Fix the launch date first

Pick the date first, then let it limit the spec. Two to six weeks is a reasonable range for a lot of software, though it depends on what you are building. If you want to launch in three weeks, only things you can build in three weeks belong on the list. Long builds also drift: the product slowly stops matching the problem and the customer you started with.

Step 4: List every feature

Write down every feature you believe the MVP needs, with a rough estimate in days. Many founders skip this. The cost is a plan that changes quietly after each conversation with a user or investor, until a three-week plan is a three-month plan. A written list at least makes the creep visible.

Step 5: Cut, then cut again

Go line by line and ask whether a truly desperate user needs this feature to start. Cut the unimportant items. If nothing unimportant is left, start cutting important ones. Anything you can do by hand for the first ten customers (account setup, data entry, invoicing) is a good candidate to come off the list. A week into the build, run the cut again. Our do things that don't scale guide covers how far manual work can stretch.

Step 6: Put measurement in the spec

Page-view analytics add little at this stage, in our view. An event-based tool from day one, tracking five to ten simple actions at first, is usually enough. For each feature, write down the number you expect it to move, as part of the feature itself.

Step 7: Ship to real users and watch

One feedback question matters most: does it solve the problem you meant it to solve? Often you don't need to ask. If users have the problem daily and your product solves it, they tend to come back the next day. If they don't come back, you've learned something too.

Step 8: Iterate on a fixed cycle

After launch, a regular release cadence (see the product cycle below) helps. Hold the customer and the problem fixed while you change the solution.

Worked example: cutting a clinic scheduling MVP from 16 weeks to 3

An illustrative case. A solo technical founder wants to help small dental clinics fill last-minute cancellations. The one-sentence problem: "When a patient cancels the same day, the chair sits empty and the clinic loses the revenue." The desperate user is a single-location clinic with a waitlist it currently works by phone.

Her first spec, estimated in developer days:

The full spec is 80 developer days, or 16 weeks for one person working five days a week. The kept items total 11 days, about 2.2 weeks, which fits a three-week timebox with a few days of slack for testing and onboarding.

Now compare the two paths over the same 16 weeks. The full build ships once, at week 16, with zero user feedback in the meantime. The MVP ships at the end of week 3, leaving 13 weeks, or six and a half two-week iteration cycles, of real usage before the full spec would even have launched.

Suppose three clinics sign on. Over the first two weeks they log 40 same-day cancellations and the SMS waitlist fills 22 of them, a 55 percent fill rate. At an assumed $150 per appointment, that is $3,300 recovered across the three clinics, or about $1,100 per clinic in two weeks. If she prices at $300 per clinic per month, the value case shows up in the first invoice.

She also charged from day one. We think that's usually the stronger test: a price filters out people who don't have the real problem, and what someone pays tells you more than what they say in an interview (our view on why purchase intent beats polite opinions).

The numbers are illustrative. The point: cutting the spec bought six rounds of learning, not just 13 weeks. Cutting scope hard is also one of the habits in our guide to second-time founder lessons.

An MVP spec template you can copy

Fill this in before you write code, and keep it in one shared document.

MVP SPEC
Launch date (fixed):
Problem, one sentence:
First user (who, where, how desperate):
How often they hit the problem / how painful it is:
What they do today instead:

Features (estimate in days, then cut):
1. ________  days: __  keep / cut / do by hand
2. ________  days: __  keep / cut / do by hand
3. ________  days: __  keep / cut / do by hand
Total kept days vs days available before launch:

Events to track (5 to 10):
The one number that says it works:
What we will do manually for the first 10 users:
First 10 users by name:
Date of first iteration review:

Checklist before you ship:

• [ ] The problem fits in one sentence and the whole team agrees on it.
• [ ] Every kept feature passes the desperate-user test: would they need it to start?
• [ ] Kept features fit inside the timebox with slack to spare.
• [ ] Event tracking ships with the product, not after it.
• [ ] You have a price, or a clear reason this user will not be charged.
• [ ] You know the first ten people who will get access.

After launch: run a product cycle

Shipping version one starts a loop. You don't need our exact process, but some cadence helps. Here is one option for a small team:

1. Set a release schedule. Every two weeks suits a mobile app with slow store review; a pure web product can run weekly.
2. Put one person in charge of product. That person owns hitting the cycle's goal, not deciding every feature.
3. Choose the metric for the cycle. For a content product, that might be new content created, new users and retained users.
4. Brainstorm without debate. Every idea goes on the board under new features, bugs or tests.
5. Grade each idea easy, medium or hard, led by whoever runs engineering.
6. Pick the hards first, then mediums, then easies.
7. Write the spec in the room and assign owners.
8. Stop debating and build until the next meeting.

One distinction we lean on: iterating means changing the solution, while pivoting means changing the customer or the problem. The first should be constant. The second should be rare. When an MVP disappoints, a sensible default is to fix the product for the same user rather than hunt for a new user who might like what you already built.

One habit we'd add from day one: have the people who build the product answer customer support. Kevin Hale, a Wufoo co-founder, calls this support-driven development. His favorite illustration is Kayak's Paul English putting a support phone on the engineering floor, where an engineer who took the same complaint two or three times simply fixed the bug. Few processes close the loop faster.

Common MVP mistakes

• Building for a year out of fear. Feeling the fear is normal. Delaying launch because of it is the mistake.
• Treating the MVP as art. A product only its maker appreciates rarely succeeds, however polished.
• Asking the wrong people. Friends and investors usually don't have the problem, so discount their product opinions.
• Giving it away out of fear. Starting free because you worry nobody will pay can attract people who don't have the problem.
• Declaring failure after two months. Finding a real solution can take closer to two years, so a flat first month is usually a reason to iterate, not pivot.
• Falling in love with version one. Love the customer. Not the MVP.

"But users expect a polished product now"

This is the strongest objection, and it deserves a fair hearing. Some founders now reject the MVP in favor of a "minimum lovable" first version. In crowded consumer categories, the bar for viable really is higher. A rough product there may get one look and no second.

Regulated industries, hard tech and biotech can't ship a working product in weeks either. And the Lean Startup camp would add that a smoke test (Eric Ries's 2009 guide points to a cheap ad-based one) can expose a bad concept before you build anything at all.

But.

Most B2B and niche products aren't competing for a bored consumer's attention. They're selling to someone in pain, and early adopters with a severe problem tolerate a lot. Our read: in a crowded consumer market, make the MVP excellent at one thing rather than decent at ten. In a heavy industry, start with a simple website explaining what you do, so the people you talk to have something to refer back to, and apply the same cutting discipline to the first pilot.

Where we land

Ries's Build-Measure-Learn loop and the ship-fast school agree on the essentials: release a minimal product early and let customer behavior decide what comes next. The difference is emphasis. The Lean Startup is explicitly experimental, built around testing hypotheses and deciding whether to pivot or persevere, and Ries stresses that an MVP is about learning, not minimalism for its own sake. The ship-fast school cares less about experiment design and more about speed and desperation.

We sit closer to ship-fast. Cheap smoke tests make sense when the risk is demand. Once you know the problem is real, get something usable to a user in pain, and treat pivots as rare rather than routine. Reasonable founders weigh this differently.

What about the famous exception? Rippling took far longer to launch because Parker Conrad had already built the category once at Zenefits. We see that as a rare case, not a model. Unless you've done the same thing before at scale, it probably doesn't apply to you.

Build your MVP with structure and a deadline

For many founders, the hardest part of an MVP is holding the line on scope when every conversation tempts you to add a feature. 1752vc's Ignite startup academy is built for first-time founders at exactly this stage, especially those working on an MVP: 12 weeks, live and remote, self-paced, with rolling admissions so you can start as soon as you are accepted. Once version one is live, the next job is finding product-market fit, and after that, learning how to launch a startup again and again. If you're not technical, the no-code MVP guide covers what you can ship without engineers.

The bottom line

An MVP isn't a small version of your vision. It's a question you put to one desperate user, as cheaply and quickly as you can. Fix the date, cut the list, charge something, and watch what people do.

The spec is what you hope they need.

The usage is what they actually came back for.

Key takeaways

• An MVP is the simplest thing you can give your first target users to see whether you deliver any value; ship something rough, quickly.
• One way to scope: fix the launch date, list every feature, cut the list hard, and try not to fall in love with the result.
• Build for desperate early adopters with a frequent, intense problem; they often tolerate a rough product that nobody else would.
• Consider shipping event tracking and a price with version one, so you learn whether people use it and value it.
• After launch, a fixed release cycle helps; change the solution freely, and the customer or problem only rarely.

Frequently asked questions

How long should it take to build an MVP?

For most software, we think weeks rather than months. A common approach is a firm deadline of roughly two to six weeks, with the spec limited to what fits inside it. Longer builds tend to drift from the original problem and delay feedback. Regulated or hard-tech companies are the usual exception and may start with a simple explanatory website instead.

What features should an MVP include?

In our view, only the features a desperate first user needs to get value on day one. It helps to write down every feature you think you need, estimate each, then ask whether that user truly needs it to start. Anything you can do manually for your first ten customers, such as account setup or invoicing, can usually come off the list.

What is the difference between an MVP and a prototype?

A prototype is built to explore or demonstrate an idea, often for the team, investors or usability tests, and may not work end to end. An MVP is a working first version that real users rely on to solve a real problem, so you can observe whether they come back. The goal is to reach the usable version quickly.

Should you charge for your MVP?

In most cases, we think yes. Starting with a price is usually a better test than starting free, because users with an intense problem tend to pay and a price filters out people who are only curious. It also gives you revenue data from the first week. If you do not plan to charge users, for example in an ad-supported product, starting free is reasonable.

How do you know if your MVP is working?

One useful question: does it solve the problem you built it to solve? Behavior tends to tell you more than opinions. If the problem occurs daily and users return the next day and keep using the product, that is a good sign it is working. If they try it once and leave, iterate on the solution for the same user before considering a change of customer or problem.

Sources

• Y Combinator: How to build an MVP (Michael Seibel)
• Y Combinator: How to plan an MVP (Michael Seibel)
• Y Combinator: Building product (Michael Seibel)
• Y Combinator: How to build product as a small startup (Michael Seibel)
• Y Combinator: How to Start a Startup, Building products users love (Kevin Hale)
• Y Combinator: Inside the Group Partner Lounge, When to launch your startup (Brad Flora, Harj Taggar, Michael Seibel)
• The Lean Startup: Principles (Eric Ries)
• Startup Lessons Learned: Minimum Viable Product, a guide (Eric Ries, 2009)
• TechCrunch: How Dropbox Got Its First 10 Million Users (2011)
• Fortune: Nick Swinmurn, Zappos' Silent Founder (2012)