How do you scope an MVP so you don't end up vibe coding something too big to ever finish?

You scope an MVP by naming the single core job your product does, then cutting every feature that isn't required for one real person to complete that job, start to finish. Everything else, even the features you're sure are must-haves, goes on a separate "later" list instead of into the build. You build one thin, fully working path through the whole app before you polish or add anything else. That's the entire method: one job, one complete path, cut hard.

I'm Mahmoud Zalt, an independent senior AI systems architect. I've shipped production software since 2010, that's 16 years, and I founded Sista AI (sistava.com), where I run a workforce of autonomous AI agents in production, not demos. I wrote the scoping chapter in The Vibecoder's Handbook because it's the step most vibe coders skip entirely, and skipping it is the single biggest reason AI-generated projects balloon into something that never ships.

What "MVP scope" actually means

MVP stands for minimum viable product, and both words are doing real work. "Minimum" means you cut ruthlessly, further than feels comfortable. "Viable" means whatever survives the cutting still works, end to end, for someone, on its own, with nothing propped up behind the scenes.

The mistake most people make is treating an MVP as a smaller, buggier version of the full product. It isn't. It's a different, narrower product that solves one problem completely. A note app MVP that lets you write a note and find it again is a finished, working thing. A note app MVP that lets you write a note, half-syncs it to the cloud, and sort of tags it is not an MVP, it's an unfinished full product, which is exactly the trap you're trying to avoid.

This distinction matters because it changes what "done" looks like. Done isn't every item on your original wish list. Done is the one job working, reliably, for one kind of user.

Why scope discipline matters even more with AI writing the code

Vibe coding removes the friction that used to naturally cap scope. When adding a feature meant hours of a developer's time and real cost, teams thought twice before saying yes to "while we're at it, let's also add..." When adding a feature means typing one more prompt, that friction disappears, and it disappears exactly when you need it most.

The catch is that complexity doesn't care who wrote the code. Every feature you add, AI-generated or not, is more surface area for something to break, more state for the system to track, more context the AI has to hold correctly when you ask for the next change. A codebase that grew from fifty prompts instead of fifty PRs still has fifty features' worth of edge cases, and now nobody, including you, has read most of it line by line.

So the AI doesn't just fail to solve the scope problem, it actively removes the natural brakes on it. That's exactly why the discipline in this chapter isn't optional advice, it's the thing standing between you and a project that grows forever without ever becoming a product.

There's a second, quieter cost. Every extra feature you generate is context the AI now has to reason about correctly on the next prompt: more files, more state, more places a fix in one spot breaks something in another. Scope discipline isn't just about your time anymore, it's about keeping the codebase small enough that the AI can still work in it reliably. A tightly scoped MVP is easier for a model to reason about too, which means fewer regressions and fewer sessions spent debugging something that used to work.

Name the one core job, then apply the test

Every real product exists to do one core job. Not five jobs, not a platform of jobs, one. Before you write a single prompt, name it in a sentence a stranger would understand.

Once you have that sentence, run every item on your feature list through one question: does this feature directly serve the core job, or does it just decorate it? If the core job would still work without it, it's decoration, however good the idea is, and it does not belong in the MVP. It waits.

This test is uncomfortable on purpose. It's supposed to filter out the features you're personally excited about, not just the obviously unnecessary ones. Excitement is not the bar. Necessity to the one job is.

Run the test on paper before you touch a prompt. List every feature you've been imagining, then mark each one pass or fail against the core job sentence. You'll usually find that fewer than half survive, and that's not a sign you were planning badly, it's a sign the test is working. The features that fail don't disappear, they move to the later list from the previous chapter's must-have work, they just don't get built this week.

Expect to cut some of your own must-haves

Here's the part that stings. Some features you genuinely marked must-have while planning still don't belong in the MVP. "Must-have eventually" and "must-have to ship the first working slice" are different bars, and confusing them is how a two-week build quietly becomes a six-month one.

None of the items in the right column are bad ideas. They're just not required for one person to complete the core job once. Sign-in with email lets someone use the app today. Sign-in with Google is a convenience layered on top of an app that already works. Build the layer once the base is real.

Build a walking skeleton, not ten half-finished features

A walking skeleton is one thin path through your entire app that actually works: someone arrives, does the core job once, and gets a real result. It's skinny everywhere, but every bone connects, front end to back end to whatever storage or AI call sits underneath.

This beats the more common instinct, which is to build many features to about fifty percent each. Ten half-finished features ship nothing a real person can use, no matter how close each one looks in your editor. One complete path, however plain it looks, is a product you can hand to a stranger tomorrow and watch them actually use.

If you're vibe coding, this also gives you a concrete way to know when to stop adding and start testing: the moment the skeleton walks, from a user's first click to a finished result, with nothing faked or stubbed out, you have something worth showing someone. Everything past that point is a separate decision, made deliberately, not by accident.

Building the skeleton first also protects you from a specific vibe coding failure mode: generating a polished-looking screen for a step that doesn't actually connect to anything real yet. It's easy to prompt your way to a beautiful checkout page before you've confirmed a payment can actually go through end to end. Wire the whole path first, however ugly, then make it look good. Polish on a broken path is wasted work the moment you fix the path underneath it.

Guard against scope creep and imaginary future users

Scope creep is the slow drift of "while we're at it, let's also..." and it's the single most common reason a vibe-coded project never finishes. Each addition feels small in the moment. The AI makes it feel even smaller, since it's just another prompt. The total, over weeks, is enormous.

A close cousin is building for imaginary future users: adding flexibility, settings, or entire features for a scale or audience you don't have yet and might never have. Multi-tenant support before you have one paying tenant. A plugin system before you have a working core. This work isn't wrong someday. It's wrong now, because it delays the one thing that tells you whether you should build any of it at all: a real person using the core job.

The fix is simple to state and hard to hold to. Write your MVP list down and treat every new idea that shows up mid-build as a candidate for a separate "later" pile, never as an edit to the current plan. The plan stays closed while you're building it. The pile stays open forever.

Do this now: take your must-have list, circle the single core job it's meant to serve, then keep only the user stories required to do that job once, end to end. Move everything else to the later pile before you write another prompt.

Frequently Asked Questions

What's the difference between an MVP and a prototype?

A prototype can be faked. Buttons that don't do anything, data that resets on refresh, flows that only work if you click in the right order. An MVP has to actually work, end to end, for a real person, even if it only does one job. A prototype proves an idea looks right. An MVP proves it works.

How small is too small for an MVP?

It's too small if the core job doesn't actually complete. A note app that lets you write a note but not find it again again later hasn't shipped the core job, it's shipped half of it. As long as one full path through the core job works without gaps, smaller is almost always better than bigger.

What if I cut a feature and it turns out users really need it?

Then you'll find out fast, from real usage, which is far more reliable than guessing upfront. That's the point of shipping the walking skeleton early: it turns "I think users need this" into "users are asking for this," and the second one is worth building. Most cut features never get requested at all.

How do I stop scope creep during a vibe coding session specifically?

Keep your MVP list open in a separate note while you prompt, and the moment an idea shows up that isn't already on that list, write it in the later pile instead of asking the AI to build it. The AI will happily build whatever you ask next, so the discipline has to come from you, not from the tool.

Should my MVP be built to scale from day one?

No. Scale is a problem you earn by having users, and solving it before you have any is exactly the kind of imaginary-future-user work this chapter warns against. Build the core job so it works correctly for one user first, then handle scale, security hardening, and edge cases once real usage tells you they matter.

The short version, and where the long version lives

Scoping an MVP is less about deciding what to build and more about deciding what to refuse, on purpose, in writing, before you start prompting. That discipline is what turns vibe coding from a way to generate endless half-finished code into a way to ship something real.

This article covers the short version. The full chapter in The Vibecoder's Handbook goes deeper, with the exact exercise to scope your own MVP from your own must-have list. Read the free chapter ->