Most MVPs don't ship in six weeks because they were never six-week MVPs. They were full products wearing a smaller name. The scope problem happens at the whiteboard, not in the sprint, and no amount of engineering velocity saves a feature list that was wrong on day one.
This is how we scope an MVP that actually ships in six weeks. It's mostly about deciding what not to build, which is harder than it sounds because everything feels essential when you're staring at it.
The one-job rule
An MVP does one job. Not the most jobs you can fit in six weeks, one.
The job is the single thing that, if it works, proves the riskiest assumption in your business. Everything else is a distraction wearing a feature request.
The test is brutal and clarifying: "If we built only this and nothing else, would we learn whether this idea works?" If yes, that's your MVP. If you need three more things before the answer means anything, you haven't found the one job yet.
A few examples of one-job framing:
- A marketplace MVP's job is "can we get supply and demand to transact once," not "build a marketplace."
- A SaaS MVP's job is "will someone pay to solve this specific pain," not "build the platform."
- An internal tool's job is "does automating this step save the time we think it does," not "replace the whole process."
Once you name the one job, the cut list almost writes itself.
The cut-list framework
Take your full feature list and sort every item into three buckets. Be ruthless. The default human instinct gets this wrong, so override it.
The Fake-it bucket is where six-week MVPs are won. You do not need to build admin panels, automated onboarding emails, billing automation, or a settings page to learn whether the idea works. You need them to run a business, and that comes after you've proven there's a business.
If your Core bucket has more than five or six items, you don't have an MVP, you have a product. Go back and cut until it hurts, then cut one more.
Build in tracer-bullet slices
Once the scope is right, build it as thin vertical slices, not horizontal layers.
The wrong way: build the entire database schema, then the entire backend, then the entire frontend, and integrate at the end. By the time anything works end to end, you're in week five with nothing to show and every integration bug landing at once.
The tracer-bullet approach: build one feature all the way through, database to UI, in the first few days, even if it's ugly and hardcoded in places. It does one thing, badly, but completely. Then you flesh it out.
A six-week shape that works:
- Week 1. Architecture spike plus one tracer-bullet slice that touches every layer. By Friday, something clicks a button and data round-trips. Thin, ugly, real.
- Weeks 2-4. Build out the core features along that proven path, one vertical slice at a time. Each one shippable on its own.
- Week 5. The unglamorous glue: error states, the empty state, the one path real users will actually take.
- Week 6. Polish, deploy, and put it in front of real users.
The reason this works is that the riskiest integration risk, "do these layers even talk to each other," is retired in week one, when you can still do something about it. We run our SaaS Development sprints on exactly this rhythm.
Instrument from day one
This is the cheapest thing you can do and the one most teams skip. An MVP exists to learn something, and you can't learn from a product you didn't instrument.
Before you ship, wire up analytics for the handful of events that answer the one job:
- Did they reach the core action?
- Did they complete it?
- Did they come back?
You don't need a data warehouse. PostHog or Mixpanel and five well-named events is enough. The failure mode is shipping the MVP, getting some usage, and then having no idea whether people actually did the thing, because you never logged it. An MVP without instrumentation is a demo, not an experiment.
An MVP you can't measure is a bet you placed without watching the table.
The scope-creep tells
Scope creep rarely announces itself. It arrives as reasonable-sounding sentences. Learn to hear them.
- "While we're in there..." No. That's a separate ticket for after launch.
- "It would be weird if it didn't also..." Maybe, but weird ships; missing-the-deadline doesn't.
- "Just to be safe, let's also handle..." Handle the common path. Edge cases are Later-bucket items.
- "The demo would be more impressive with..." Impressive isn't the goal. Learning is.
- "Can we make it configurable?" Hardcode it. Configurability is the most expensive way to avoid a decision.
When you hear one of these, the move is the same every time: name the bucket out loud. "That's a Later item, adding it to the roadmap." Said early and often, that one sentence is what keeps six weeks from becoming six months.
The scope conversation that prevents all of this
The single highest-leverage thing you can do is a one-hour scoping conversation before any code, where you and whoever's building agree on three things in writing:
- The one job this MVP proves.
- The Core list (five or six items, max).
- The Later list, so deferred work has a visible home and stops trying to sneak into v1.
Get those on one page and signed off, and the build is almost boring. That's the goal. Boring ships.
If you've got an idea and a deadline and you're not sure what's actually in v1, that's the conversation we have at the start of every MVP Sprint. Send us the idea and the date you want it live, and we'll help you find the one job.
Read next:
- What custom software actually costs in 2026
- Build vs buy: a framework for custom software
- Adding AI to a product that isn't AI-first
Related: