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.
1.3.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.
1.3.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?
| Product | The one core job |
|---|---|
| A note app | Write a note and find it again |
| A store | Buy one item and pay |
| A booking tool | Reserve 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.
1.3.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 MVP | Pushed to later |
|---|---|
| Sign in with email | Sign in with Google, Apple |
| Post one item for sale | Bulk upload, drafts, scheduling |
| Pay with one card | Saved cards, refunds, coupons |
| One language | Translations |
1.3.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.
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.
1.3.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.
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:
Act as a senior engineer scoping my MVP. 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.
My user stories:
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.
