FajarMost MVPs do not fail in the code. They fail at the whiteboard, weeks before the first commit, when somebody says “and it should also have...” and nobody in the room says no. Engineering skill and budget matter less to the ship date than scope does.
First, a plain statement about the number in this post’s address. A typical MVP takes 8 to 12 weeks, and that is the range we quote. Six weeks is possible only for a tightly cut first version: one platform, one core flow, and no custom integrations. This post explains how to scope for either timeline, and how to tell which one you are really looking at.
When Six Weeks Is Realistic, and When It Is Not
Six weeks can hold a product that meets all of these conditions:
- One platform, which in practice means a responsive web app.
- One user role and one core flow.
- No custom integrations. Hosted services with good documentation (login, payments, email) are fine. A client’s ERP, a partner API with a sandbox that half works, or a data migration is not.
- Designs and third-party accounts ready before the build starts.
- One person on the client side who can make scope decisions within a day.
Miss any one of these and you are in the typical 8 to 12 week range. That is not a failure. Two user roles, a native app, an integration or a regulated domain each add real work, and a plan that pretends otherwise slips later and costs more. If budget is the constraint behind the deadline, what a custom web app costs in 2026 breaks down where the money goes.
Start With the One Loop That Proves the Business
A product has one core loop: the repeatable action that, if people do it willingly, shows 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.
The MVP is that loop made real, and very little else. Write the loop as one sentence before writing any user story. If you cannot, you are still in product discovery, and no engineering timeline will fix that.
A second user role roughly doubles the surface: two onboarding flows, two dashboards, two sets of notifications and edge cases. If the product truly needs both sides, consider running one of them by hand at launch. A marketplace whose supply side lives in a spreadsheet for the first month, with the founder doing data entry, is sequencing the work correctly.
The Cut List
A founder’s first spec often describes 20 screens. A tightly cut first version has closer to 6 or 8. These are the things we propose cutting first, and why the product survives without them.
Custom Authentication
Password resets, email verification and session handling take real engineering time and teach you nothing about your market. A hosted service such as Supabase Auth or Clerk gets login working quickly, and you can migrate later if you ever need to.
The Admin Panel and Settings Pages
For the first hundred users, administration can be careful database access plus an internal tool builder. Building a custom admin interface before you know what needs administering is waste. The same goes for profile editing, notification preferences and theme toggles: ship sensible defaults.
Notification Infrastructure
No in-app notification center, no push, no digest emails. Send one transactional email at the most important moment in the loop (order confirmed, report ready) and stop there.
Most Edge Cases
Handle the happy path and the single most likely failure, such as a declined payment or a failed upload. Everything else gets a generic error state and a log entry. Production data will show which edge cases occur, and they are often not the ones you guessed.
Native Mobile
A responsive web app reaches every device on the first day. If the loop needs the camera or an installable app, a progressive web app covers a good share of those cases. If it truly needs native features, that belongs in the 8 to 12 week plan, and when to choose Flutter may help with the framework decision.
What Stays In
Hard scoping has a failure mode of its own: cutting the things that make the MVP a valid experiment. Three things stay.
The first is payments, if revenue is the hypothesis. If the question is “will people pay?”, a checkout is the experiment. Collecting email addresses tests a different and much weaker question. A hosted payment page such as Stripe Checkout keeps the integration small.
The second is error tracking and one funnel. Set up Sentry or an equivalent at the start, plus analytics events on each step of the core loop and nowhere else. Five events, not fifty. Without them a launch produces anecdotes where you wanted data.
The third is the 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 plain.
The Week-by-Week Shape of a Six-Week Build
Notice how little of this is “writing features.”
Before the Clock Starts
A scoping workshop, the one-sentence loop, the cut list agreed in writing, wireframes for the 6 to 8 screens, and each third-party service chosen. The build should not start until accounts and API keys for login, payments, email and hosting exist. A payment account that is still in verification in week four stops the project.
Weeks 1 and 2: The Walking Skeleton
By the end of week two, a user can go through the whole core loop in a deployed environment. It is ugly and minimal, and it is real, with automated checks running on each change. This forces the hard questions (login, data model, third-party APIs) to surface in week one and not week five. It is also the first of the demos of working software that we hold every two weeks.
Weeks 3 and 4: Make the Loop Good
Proper validation, the one designed screen polished, the transactional email, the payment failure handled, empty and loading states on the core flow. This is the window for scope changes, described below.
Week 5: Hardening
Feature freeze. The week goes to rate limiting, input validation, testing at phone widths, a load test above expected launch traffic, a backup restore test, and fixing what the team finds by using the product themselves. The OWASP Top 10 is a sensible review list for this week.
Week 6: Soft Launch
Real users, perhaps 10 to 50 of them, invited and not announced. Someone watches the instrumentation daily, and what breaks gets fixed quickly. By the end of the week you have production data about the core loop, which was the purpose all along.
The 8 to 12 week version has the same shape. The skeleton phase takes longer when there is an integration or a second role, the middle phase grows with the number of flows, and hardening and soft launch stay about the same length.
Handling Scope Pressure
New information does arrive in the middle of a build, so scope pressure is a structural problem more than a discipline problem. Two mechanisms handle it better than willpower does.
A change budget. Keep a visible reserve, around 15% of the build, labeled for changes. When a stakeholder wants something new, the question stops being “can we?” and becomes “which item does this replace, or does it come out of the reserve, which now has this many days left?” A trade is easier to decide than an argument is to win. On a Fixed-Price Project the same principle is written into the agreement: the agreed scope, nothing more, with changes handled as explicit trades. Our comparison of fixed-price and monthly engagement models covers which one suits which kind of uncertainty.
The v1.1 list. Each cut feature and each new idea goes onto a visible, ordered list. People fight to keep a feature that is being deleted, and they will readily defer the same feature. Two weeks after launch, half of that list tends to look irrelevant, because by then you have real data.
Team Shape and Decision Speed
Small teams build tightly cut MVPs. A common shape is two engineers (one leaning back end, one leaning front end), a designer at about half time and weighted toward the early weeks, a project lead, and a product owner on the client side, usually the founder. The constraint that teams underestimate is decision speed. A decision that waits four days for a meeting uses up a tenth of a six-week timeline. Without a named decision-maker who answers within a day, plan for the longer range from the start.
What an MVP Is For
An MVP is not a small version of your five-year vision. It is an instrument for answering one question about your business at the lowest reasonable cost. When a build overruns, slow engineering is seldom the cause. More often the product was quietly being asked to answer six questions where it should have answered one.
Get the one-sentence loop right, cut what does not serve it, and protect the cut list with structure. Then be honest about the conditions: if they all hold, six weeks is enough; if they do not, 8 to 12 weeks is the normal, healthy answer. Our product engineering team runs scoping this way. Bring your spec and request a call, and we will tell you plainly which timeline it fits.
