How to Scope an MVP That Actually Ships in 6 Weeks

Most MVPs do not fail in the code. They fail at the whiteboard, three weeks before a single line is written, when somebody says "and it should also have..." and nobody in the room says no. We have run dozens of six-week MVP builds at Fajarix, and the pattern is consistent: the projects that ship on time are not the ones with the best engineers or the biggest budgets. They are the ones with the most disciplined scope. This post is the scoping framework we actually use — the one we walk clients through in week zero, before any contract is signed.

Start With the One Loop That Proves the Business

Every product has exactly one core loop — the repeatable action that, if users do it willingly, proves the business works. For a marketplace, it is post a listing → receive an inquiry → close a deal. For a B2B analytics tool, it is connect a data source → see an insight → act on it. For a booking product, it is search → book → show up.

Your MVP is that loop, made real, and almost nothing else. Write the loop as a single sentence before you write a single user story. If you cannot express your product's core loop in one sentence, you are not ready to scope an MVP — you are still doing product discovery, and no engineering timeline will save you.

We enforce a hard rule on six-week builds: one user role, one platform, one core loop. Two roles (say, buyers and sellers) roughly doubles the surface area — two onboarding flows, two dashboards, two notification schemes, two sets of edge cases. If your product genuinely needs both sides, fake one of them for launch. Plenty of successful marketplaces launched with the supply side managed manually through a spreadsheet and a founder doing data entry. That is not a hack; that is correct sequencing.

The Cut List: What Comes Out, Every Time

When a founder brings us a spec, it typically describes 15 to 25 screens. A shippable six-week MVP is 6 to 8 screens. Here is what we cut first, and why the product survives without it:

• Custom authentication. Password reset flows, email verification, session management — this is two weeks of engineering that produces zero learning. We default to Clerk or Supabase Auth and get login working in an afternoon. You can migrate later; almost nobody ever needs to.
• The admin panel. For the first 100 users, your admin panel is direct database access plus a tool like Retool or even Prisma Studio. Building custom admin UI before you know what you need to administer is pure waste — we have seen teams spend 30% of an MVP budget here.
• Settings pages. Profile editing, notification preferences, theme toggles. Users testing whether your core loop is valuable do not care. Hardcode sensible defaults.
• Notifications infrastructure. No in-app notification center, no push, no digest emails. One transactional email at the single most important moment in the loop (order confirmed, report ready) sent via Resend or Postmark. That is it.
• Edge-case handling beyond the happy path plus one. Handle the happy path and the single most likely failure (payment declined, upload failed). Everything else gets a generic error state and a log entry. You will learn which edge cases actually occur from production data, and it will not be the ones you guessed.
• Native mobile. A responsive web app reaches every device on day one. If the core loop demands the camera or push notifications, wrap the web app; do not start a second codebase.

What We Never Cut

Ruthless scoping has a failure mode: cutting the things that make the MVP a valid experiment. Three things stay in every build, no exceptions:

• Payments, if revenue is the hypothesis. If the question your MVP answers is "will people pay?", a Stripe checkout is the experiment. An MVP that collects email addresses instead of money tests a different, much weaker hypothesis. Stripe Checkout takes two days to integrate; there is no excuse.
• Error tracking and one funnel. Sentry from day one, plus analytics events on every step of the core loop — and only the core loop. Five events, not fifty. Without this, your launch produces anecdotes instead of data.
• The moment of polish that carries the value. Every product has one screen where the value lands — the generated report, the matched result, the confirmation. That screen gets real design attention. The rest of the app can be clean and boring.

The Week-by-Week Shape

Here is how a six-week build actually breaks down when it works. Notice how little of it is "writing features."

Week 0 (Before the Clock Starts)

Scoping workshop, the one-sentence loop, the cut list signed off in writing, designs for the 6-8 screens at wireframe-plus fidelity, and every third-party service chosen. We do not start week one until API keys for auth, payments, email, and hosting exist. Teams that "figure out the Stripe account later" lose four days to procurement in week four, every time.

Weeks 1-2: The Walking Skeleton

By the end of week two, a user can traverse the entire core loop end to end in a deployed environment — ugly, minimal, but real. Deployed to production infrastructure from day three, with CI running. The walking skeleton forces every hard integration question (auth, data model, third-party APIs) to surface in week one instead of week five, which is the single biggest reason our timelines hold.

Weeks 3-4: Make the Loop Good

Now the loop gets real: proper data validation, the one designed screen polished, the transactional email, payment edge case handled, empty states and loading states on the core flow. This is also the only window where we accept scope changes — more on that below.

Week 5: Hardening

Feature freeze. The week is spent on the unglamorous work that separates a demo from a product: rate limiting, input sanitisation, mobile-width testing, a load test with 10x expected launch traffic, backup verification, and fixing everything the team finds by using the product themselves for two full days. We schedule zero feature work in week five, and we mean zero.

Week 6: Soft Launch

Real users — 10 to 50 of them, invited, not announced. Instrumentation watched daily. The team fixes what breaks within hours. By the end of week six you have production data about your core loop, which was the entire point.

Handling Scope Creep Without Being the Villain

Scope pressure is not a discipline problem; it is a structural one. New information genuinely does arrive mid-build. So we build two mechanisms into every engagement instead of relying on willpower:

• A change budget. Every build carries roughly 15% slack explicitly labelled for mid-project changes. When a stakeholder wants something new, the question is never "can we?" — it is "which of these does it displace, or does it come out of the change budget, which is now down to X days?" Framing scope as a zero-sum trade converts arguments into decisions.
• The v1.1 parking lot. Every cut feature and every mid-build idea goes onto a visible, ordered list titled "v1.1." This matters psychologically: stakeholders fight to keep features that are being deleted, but they will happily defer the same features. Two weeks after launch, half the parking lot will look irrelevant — because now you have real data.

A Note on Team Shape

Six-week MVPs are built by small teams. Our default is two engineers (one leaning full-stack/backend, one leaning frontend), a designer at roughly half allocation front-loaded into weeks 0-2, and a product owner — usually the founder — who can make scope decisions within 24 hours. That last constraint is the one clients underestimate. A decision that waits four days for a stakeholder meeting costs you 10% of the timeline. We ask clients for a named decision-maker with a 24-hour SLA, and when we do not get one, we quote eight weeks instead of six.

The Uncomfortable Truth About Six Weeks

Here is our honest position: almost any MVP can ship in six weeks, but only if you accept what an MVP is for. It is not a small version of your five-year vision. It is an instrument for answering one question about your business at the lowest possible cost. When teams miss six-week timelines, it is almost never because the engineering was slow — it is because the product was quietly being asked to answer six questions instead of one.

Scope is a product decision disguised as an engineering constraint. Get the one-sentence loop right, cut everything that does not serve it, protect the cut list with structure rather than willpower, and six weeks is not aggressive. It is just enough time.

If you have a product that needs to get in front of users this quarter, our product engineering team runs exactly this playbook — scoping workshop included. Book a free consultation and bring your spec; we will tell you honestly what six weeks can hold.