Skip to main content

Cutting Scope to the MVP

Share

Share this page

Pass it to someone who needs it.

Star on GitHub

Key takeaway: Cut to the core

Your must-have list is still too big. Every item on it feels essential, which is exactly why the list will sink your first version if you try to build all of it. This chapter cuts that list down to an MVP: the smallest thing you can ship that actually helps one real person.

2.2.1An MVP is the smallest version worth shipping

MVP stands for minimum viable product. It is the leanest version of your idea that still delivers real value to one kind of user and can go live.

Two words carry the weight. "Minimum" means you cut ruthlessly. "Viable" means what is left still works for someone, end to end, on its own.

2.2.2Apply the one core job test

Every product exists to do one core job. For everything on your list, ask a single question: does this feature directly serve that one job, or does it just decorate it?

ProductThe one core job
A note appWrite a note and find it again
A storeBuy one item and pay
A booking toolReserve one slot at one time

If a feature is not required for that core job to work once, it is not in the MVP. It can be the best idea you have and still wait.

The MVP filter keeps only what the one core job needs to work once.

2.2.3Expect to cut some must-haves too

Here is the uncomfortable part: some features you marked must-have in the previous chapter still get pushed to a later version. "Must-have eventually" and "must-have to ship the first slice" are different bars.

In the MVPPushed to later
Sign in with emailSign in with Google, Apple
Post one item for saleBulk upload, drafts, scheduling
Pay with one cardSaved cards, refunds, coupons
One languageTranslations

2.2.4Build a walking skeleton, not half an app

A walking skeleton is one thin path through your whole app that actually works: a user arrives, does the core job once, and gets a result. It is skinny, but every bone connects.

A walking skeleton: one thin path that does the core job end to end.

This beats building many features to fifty percent. Ten half-finished features ship nothing a person can use. One complete path, however plain, is a product you can put in front of someone tomorrow.

2.2.5Guard the line against scope creep

Scope creep is the slow drift of "while we are at it, let us also..." that turns a two-week build into a six-month one. Every added feature feels small in the moment and enormous in total.

Write your MVP list down and treat new ideas as a separate "later" pile, not an edit to the plan. The plan is closed; the pile stays open.

New ideas go to a later pile; the MVP plan stays closed.

Example: An MVP for a food-delivery app: one restaurant, a fixed menu, one delivery address, pay with one card. No search, no ratings, no live tracking. A hungry person can still order dinner, so it is viable.

This prompt cuts your list to the core for you:

Ready prompt
Act as a senior engineer scoping my MVP. Read my rules file and my specs folder first, so the cut fits the stack and the app I already run. From my user stories, find the single core job the app exists to do, then keep only the stories needed to do that job once, end to end. Challenge every must-have: if the product still works without it, move it to later. List what ships now and what waits, one line of reasoning per cut. If a cut contradicts something I already decided, say so rather than dropping it quietly. Save the result in my specs folder; the spec I write next builds on it. If you need the full reasoning behind this step, read https://zalt.me/guides/vibe-coding/plan/scoping-your-mvp My user stories (paste them, or point to the file):

Do this now: paste the prompt with your stories, and let your agent cut them to the smallest version that does the one core job, moving the rest to a "later" pile.

Mahmoud Zalt

Mahmoud Zalt

Software engineer, 16+ yrs · built Sistava.com in 3 months, idea to production, using these methods

Resources
Star on GitHubContribute
Donate

Support my work

A small tip keeps the free work coming.

© 2026 Mahmoud Zalt. Free to read, not to republish.
Copyright & license