MVP scope: what NOT to build matters more

The term MVP — minimum viable product — came from Frank Robinson and went mainstream with Eric Ries's book "The Lean Startup" (2011). The load-bearing word is minimum. It's also the word beginners hear worst: after "nobody needs it", the biggest killer of launches is "it never shipped" — the product swelled with features and never made it out the door. This lesson is about the knife you cut scope with.

The key user loop

Describe the ONE path people pay for: arrives → does the main thing → gets the value → comes back. Example (a call-summary service): upload a recording → get notes with action items → send them to the team. Anything that isn't on that loop isn't MVP.

The classic case: the first version of Instagram was called Burbn and did check-ins, meetup plans, points and photos. Users only ever touched the photos. Kevin Systrom cut everything else and kept one loop: shoot → filter → post. Two years later Facebook bought it for a billion dollars. The loop carries the product; the extras sink it.

The scope knife: three lists

1. Now (the loop + sign-in + payment): without this there's no product.
2. Later (once you have real users): themes, integrations, teams, settings.
3. Not-for-now (the temptations): a mobile app, an API, a marketplace. Write it down, then forget it until you have a hundred customers.

The test for every feature: "Would a user walk away in month one if this were missing?" No — it goes on list two. That one question saves weeks.

A Socratic pause

You're about to add "notification settings" to the MVP. Stop your hand and ask: would a single person leave in month one if notifications just worked on sensible defaults, with no settings? The answer is almost always no. Which means: "later" list.

Beginner myths

• "An MVP is a bad product." No. It's a narrow but good product: one thing done well, not ten done badly.
• "It won't fly without social login / dark mode / a mobile app." Things fly on the bare loop. The polish gets added on top of real users.
• "I'll add it just in case." "Just in case" is the most expensive phrase in software. Every feature is code, bugs and maintenance — forever.

The product brief for AI

We take the brief from the vibe coding course and grow it into a product brief:

Product: [name] — [for whom] — [core value].
Loop: [the user's steps].
Pages: landing, sign-in, the app (one working screen!), minimal settings.
Data: [entities and fields — as taught in the database lesson].
Not in the MVP: [the "later" list — put it right in the brief so the AI doesn't build extras].
Style: [reference + palette].

That "not in the MVP" line is the secret ingredient. An AI assistant (a model that writes code from your description) loves to be helpful and fill in the gaps: ask for a sign-in form and you'll get password recovery, two-factor auth and a profile settings page thrown in. An explicit ban keeps the scope on a leash.

Pace and diagnosis

An MVP built from this brief in Lovable/Replit takes 2–4 weeks of evenings. If your estimate comes out longer, the scope is still fat: cut the loop down to a single scenario. The rule is simple — the question isn't "what else could I add", it's "what else can I throw out while keeping the loop intact". Every discarded thing is a day you didn't waste.

Where this goes wrong: "I can't cut anything, it's all important"

The most common pushback in this lesson sounds like: "but everything in my product connects, nothing can go." That's almost always the illusion of standing too close to your own idea. Test it honestly: take the feature you "can't remove" and picture a user who never opens it in month one. Do they still get value? If yes, that feature isn't on the loop — it can and should wait. You cut scope not because the features are bad, but because right now they're keeping the product from shipping. Postponed isn't discarded; it's waiting its turn on the "later" list.

How this links to other courses

The data and entities for the brief (what to store and how) get their own lesson on accounts and data later in this course, and the basic build-from-a-brief technique lives in the vibe coding course. Here the brief turns from technical into product-shaped — with that explicit "not in the MVP" line.

Do this now (5 minutes)

Take your idea from the last lesson and write the loop as one line of arrows. Then list everything that wants into the product and sort it honestly into the three lists. If "Now" has more than 5 items, keep cutting.