What a 4–6 Week MVP Actually Includes
The scope that fits a four-to-six-week MVP, the parts that never get cut, and why auth, payments, admin and deploys eat most of the budget.
A four-to-six-week MVP is not a faster build. It is a smaller question. The window holds because the scope is settled before anything is written — the two or three flows that carry the question, the data model underneath them, and nothing else — and it stops holding the moment the scope becomes a list of features instead of a question with a yes-or-no answer.
That distinction is worth being blunt about, because “MVP” gets used for two different things. One is a real application, deployed, instrumented, and in front of users, answering whether people will do the thing. The other is a small version of the full product, which is not an MVP; it is a full product with a deadline problem. The first fits in four to six weeks. The second is the two-to-four-month custom build wearing a disguise, and pretending otherwise is how projects arrive at week seven with no working auth.
The parts that never get cut
Every MVP we ship carries the same floor, because each item on it is either load-bearing for the question or unrecoverable if skipped.
- Real authentication. Sessions, password reset, invite or signup, and logout that actually invalidates. Not because auth is interesting, but because you cannot ask a stranger to use a product that stores their data behind a shared password.
- Payments, if money moves in the question. If the thing being tested is willingness to pay, a fake checkout tests nothing.
- An admin surface. Whatever the team needs to answer support questions and fix data without a database client. This is the item most often proposed for cutting and most often regretted within a week of launch.
- Deploys, environments and rollback. A pipeline, a staging environment, migrations that run automatically, and a way back.
- Error tracking and structured logs. An MVP with no observability produces anecdotes instead of answers.
- Backups you have restored once. An untested backup is a belief.
- A data model that can carry version two. Including a tenant column if the product is ever plausibly multi-tenant — that is one column now and archaeology later.
Notice how little of that is the product. That is the point of listing it.
What gets cut, and how to cut it without paying twice
The cuts that work remove variation, not quality. The cuts that hurt remove the floor above and hope nobody notices.
| Usually cut | Kept as | Why it is safe |
|---|---|---|
| Roles and permissions | Two roles: user and staff | Roles are additive if the check is centralised from day one |
| Notification channels | One channel, usually email | The template and trigger logic survive; the transport is swapped |
| Self-serve onboarding | Manual provisioning by you | You want to talk to the first users anyway |
| Native mobile apps | Responsive web or a PWA | Store review alone can consume a week you do not have |
| Localisation | One language, but no hardcoded strings in components | Extraction later is mechanical; rewriting components is not |
| Real-time updates | Polling on the two screens that need it | Swappable behind the same client interface |
| Bulk import, exports, reporting | A CSV export and a database query | Reports are cheap to add once you know which ones are asked for |
| Third-party integrations | The one that carries the question | Each additional system is its own project — POS sync is the clearest example |
The rule underneath the table: cut things that can be added behind an existing seam, keep things that would require re-cutting the seams. Roles can be added if authorisation goes through one function. A second notification channel is easy if sending goes through one service. Multi-tenancy is not easy to add later at all, which is why the tenant column is on the floor list and per-tenant branding is not.
Why the boring parts eat the budget
Because they are not small — they are only familiar. Four examples, each of which is a week of work masquerading as a checkbox:
Auth is roughly a dozen flows, not one screen. Signup, login, logout, password reset, expired reset token, email verification, invite acceptance, invite to an existing account, session expiry mid-form, and the one that always surfaces late: two people signing up for the same organisation independently. Add email deliverability — a reset link that lands in spam is an outage that never pages anyone.
Payments are mostly the failure paths. The charge is the easy part. The work is webhook handling, retries, idempotency so a replayed event does not double-charge, refunds and partial refunds, failed renewals, card expiry, disputes, and the reconciliation job that tells you the payment provider and your database still agree. If a subscription is involved, add the state machine — trialling, active, past due, cancelled, reactivated — and every screen that has to render each state correctly.
Admin is a product, and its user is you. It is the screen the team opens twenty times a day during a launch, and the moment it does not exist someone starts running UPDATE statements against production at 11pm. Even a deliberately plain admin needs search, a record view, the four or five actions support actually performs, and an audit trail of who did what.
Deploys are a system, not a command. Environments, secrets, database migrations in the release path, a rollback that does not lose the last hour of data, domains and certificates, and — for anything customer-facing — the difference between a deploy and a database change, which are not the same risk and should not be the same button.
None of this is exotic. It is simply where the hours go, and an estimate that does not name it is an estimate that will be wrong by the same amount every time.
Where the weeks actually go
The four phases do not change for an MVP; they compress. Discovery and scope settle the question, the flows and the data model, and produce a fixed estimate. Design and architecture happen up front rather than during the build, because mid-build architecture is what turns six weeks into ten. The build runs in weekly sprints with working software at the end of each — an MVP that is only demonstrable in week six is not being built in sprints, it is being built in one long sprint with checkpoints. Launch means deployed, monitored and in front of real users, with the feedback loop running inside the same sprints.
The compression comes from one place: the number of open decisions. A four-week build with everything decided beats a six-week build with three architectural questions still open, every time.
What happens after week six
If the question comes back answered, the MVP gets extended rather than replaced. That only works if it was built on the same stack, infrastructure and standards as a full platform, which is why the floor list has no shortcuts in it. Extending typically means the two-to-four-month path toward a full custom application, or — if the answer was “yes, and every customer wants their own instance of it” — the multi-tenant SaaS path, which is a genuinely different architecture conversation.
If the question comes back answered the other way, you spent four to six weeks finding out. That was the point, and it is the cheapest possible version of that outcome.
Three questions that tell you whether six weeks is realistic
- Can you write the question as one sentence with a yes-or-no answer? “Will independent tutors pay to take bookings through us?” is a question. “A tutoring platform” is a product.
- How many external systems must work for the question to be answered? Zero or one is an MVP. Three is a custom build, whatever you call it.
- Who decides, and how fast? A four-week build has roughly twenty decisions in it. If each needs a committee, the calendar sets the timeline, not the engineering.
If the answers point at something larger than an MVP, that is useful information to have before the estimate rather than after it. That conversation is the first phase of every engagement — tell us the question you are trying to answer and we will tell you whether six weeks can answer it.