Why does an MVP take six months instead of six weeks?

Because nobody wrote down what the MVP was, so there was never a basis for saying no. Nobody decides to build a big product. They make fifty small decisions that each sound reasonable against the full vision, and the full vision is the only reference point available when the minimum one was never defined.

What should an MVP spec contain?

One hypothesis in a sentence, a specific first user, the smallest flow that tests the hypothesis with that user, a success metric with a deadline, and an explicit not-building list. It fits on one page. Anything longer is a product spec wearing an MVP label.

How do you define minimum in minimum viable product?

By tying it to the hypothesis rather than to competitiveness. The question is not what would be nice or what rivals have, it is what is the least you can build to learn whether the hypothesis holds. If a feature could be removed without changing what you learn, it is not part of the minimum.

How do you stop scope creep during an MVP build?

Write the not-building list before the build starts and treat it as the answer to every mid-build suggestion. Read receipts, email digests and portfolio uploads are all defensible in isolation, which is exactly why the decision has to be made in advance rather than in the moment somebody asks.

Do startups really need requirements documents?

Not a fifty-page PRD, but yes to a written answer for a handful of questions. Skipping it feels like moving fast and reliably costs more time than it saves, because every undocumented assumption gets renegotiated in conversation, repeatedly, for the length of the build.

Why Your MVP Takes 6 Months Instead of 6 Weeks

The 6-Week MVP That Took 5 Months

A founder I know planned a straightforward MVP. A marketplace connecting freelance designers with small businesses. Simple listings, basic messaging, Stripe payments. He estimated six weeks to launch.

Five months later, the app had a review system, a portfolio builder, a recommendation engine, an admin dashboard with analytics, and a notification system with email digests. The marketplace still didn’t work properly because the core matching flow kept getting deprioritized for new features.

He never wrote down what the MVP actually was. So every conversation with his dev team became an opportunity to add “just one more thing.”

This story isn’t unusual. It’s the default.

Why MVPs Bloat

The word “minimum” is doing a lot of heavy lifting in “minimum viable product,” and most founders never define what it means for their specific case.

Here’s what typically happens. A founder has a vision for the complete product. It’s a big, beautiful vision. They know they should start small, so they call it an MVP. But the vision is still the reference point. Every feature decision gets evaluated against the full picture, not the minimum one.

Then the conversations start:

“While we’re building the profile page, shouldn’t we add portfolio uploads?”

“If we’re doing messaging, we should probably add read receipts.”

“Users will expect email notifications. That’s table stakes.”

Each addition sounds reasonable in isolation. None of them are strictly necessary to test the core hypothesis. But nobody defined what “necessary” means, so there’s no way to say no. The scope grows by accretion. Nobody makes a single decision to build a big product. They make fifty small decisions that add up to one.

The Real Problem Is Skipping Requirements

Founders skip the requirements phase because it feels like bureaucracy. Writing specs is what big companies do. Startups move fast. You don’t need a document; you need a product.

Except you do need a document. Not a fifty-page PRD. Not a formal spec. Just a clear, written answer to a handful of questions:

What hypothesis are we testing? If you can’t state this in one sentence, you’re not building an MVP. You’re building a product.

Who is the first user, specifically? Not “small business owners.” Something like “solo freelancers who currently find clients on Instagram and want a dedicated platform.”

What is the smallest thing we can build to test the hypothesis with that user? This is where discipline matters. Not “what would be nice.” Not “what would be competitive.” What is the absolute minimum?

What are we explicitly NOT building? This is the most important section and the one founders skip. Write it down. “No admin dashboard. No email notifications. No review system. These are v2.”

A One-Page Spec Changes Everything

Here’s what a useful MVP spec looks like. It fits on one page:

Hypothesis: Freelance designers will pay $20/month for a platform that connects them with pre-qualified small business clients.

First user: Solo freelance designers doing under $5k/month in revenue.

Core flow: Designer creates profile. Client posts a brief. Designer gets matched and sends a proposal. Client accepts. Payment happens off-platform for v1.

Success metric: 10 designers sign up and send at least one proposal within 30 days.

Not building: Reviews, portfolios, in-app payments, analytics, email digests, mobile app.

That’s it. Everything the dev team needs to make decisions is on one page. When someone suggests adding portfolio uploads, you point at the page. “That’s in the ‘not building’ section. Let’s revisit after we hit our success metric.”

How to Say No to Features

The one-page spec gives you something to point at, but you also need a decision framework for the features that aren’t on either list.

Ask three questions about any proposed feature:

Does removing this feature prevent us from testing the hypothesis?
Will users literally not be able to complete the core flow without it?
Will we learn something critical from including it that we can’t learn without it?

If the answer to all three is no, it’s not in the MVP. Put it on a “v2 ideas” list so people feel heard, and move on.

Ship the Minimum, Then Learn

The founder I mentioned eventually shipped a stripped-down version of his marketplace. It took two more months after he finally cut scope. The thing that actually mattered, the matching algorithm, turned out to need a completely different approach than he’d planned. He would have discovered that five months earlier if he’d shipped the minimum first.

Your MVP isn’t a small version of your product. It’s a test. Treat it like one. Write down what you’re testing, build only what you need to run the test, and ship it before you’re comfortable.

The features you’re desperate to add will still be there after you’ve talked to real users. And you’ll have actual data to decide which ones matter.