What an MVP Should (and Shouldn't) Include in the First 6 Weeks
A scoping framework for deciding what actually belongs in a minimum viable product — and the features founders almost always want to add too early.
The most common way an MVP timeline slips isn't bad engineering — it's scope creep disguised as reasonable feature requests. Almost every founder we talk to wants to add "just one more thing" before launch, and almost every one of those things could safely wait. Here's a framework for telling the difference.
Start from the one loop that proves the idea
Every product has one core loop — the sequence of actions that proves whether the idea actually works for a real user. For a marketplace, it might be "list an item → someone finds it → a transaction happens." For an AI tool, it might be "upload a document → ask a question → get a grounded answer." Everything the MVP includes should exist to make that one loop work end to end, reliably, for a real user. Everything else is a candidate to cut.
What almost always belongs in the first version
- The core loop itself, built properly — not mocked, not hardcoded, actually working.
- Enough error handling that the product doesn't silently fail on the first bad input a real user gives it. This isn't scope creep; it's the difference between a demo and a product.
- Basic authentication, in its simplest workable form.
- Automated tests for the core loop. Skipping this to save a few days almost always costs more time during the second version, when the codebase needs to change under real load without breaking.
- Enough analytics to see whether the core loop is actually being used, and where people drop off.
What almost always belongs in a later version
- Granular permissions and role hierarchies — unless the product is explicitly a permissions tool, most early users don't need this yet.
- A settings page with a dozen configuration options. Defaults are fine until a real user asks for the option.
- Multiple payment providers, or complex billing tiers, before there's a single paying customer to validate pricing against.
- A polished admin dashboard beyond what's needed to operate the product day to day.
- Support for edge cases with no evidence anyone will hit them yet.
The test we use to scope a feature request
When a feature comes up mid-build, we ask: if we launched without this today, what would actually happen? If the honest answer is "a slightly worse experience for some users," it's a fast-follow, not a blocker. If the answer is "the product doesn't do the thing it claims to do," it's core, and it stays in scope.
Why this matters more than it seems
A bloated MVP doesn't just take longer to build — it takes longer to learn from. The entire point of an MVP is to get real usage signal as fast as possible, so you know what to build next with evidence instead of guesswork. Every feature added "just in case" delays that signal without adding to it.
FAQs
Should an MVP include user authentication?
Usually yes, in a minimal form — but "minimal" matters. Email/password or a single social login is enough; multi-provider SSO, role hierarchies, and granular permissions are almost always premature for a first version unless the product's entire value proposition depends on them from day one.
Is it okay to launch an MVP without automated tests?
No — this is one of the few things not worth cutting. Skipping tests to move faster in an MVP usually costs more time later, once the codebase needs to survive its first real users and second version. Scope features down, not engineering discipline.
How do you decide what's "core" versus "nice to have"?
Ask what breaks the product's core promise if it's missing. If the answer is "nothing, users just have a slightly worse experience," it's not core — defer it. If the answer is "the product doesn't actually solve the problem without it," it belongs in the first version.