What an 8-Week MVP Actually Has to Cut

Founders rarely ask us to build less. They ask us to build faster, and the only way to actually deliver that is to be explicit about what isn't going in the first version — not quietly, not by accident, but as a decision someone signs off on.

An 8-week MVP timeline isn't a smaller version of a 6-month build. It's a different document with a different set of priorities, and most of the time saved doesn't come from typing code faster. It comes from not building things a 6-month roadmap would have included by default.

Start from the one thing that has to be true

Before any architecture discussion, we want one sentence: what does this product have to prove, to whom, in order for the next stage of the business to happen? A fundraising demo, a pilot customer's sign-off, and a paying user base each demand a genuinely different MVP, even if the long-term product vision is identical.

That sentence is the filter for every feature decision that follows. If a feature doesn't move that one proof forward, it's a candidate for week 9, not week 1.

What we cut first

• Admin tooling. Early on, a founder running raw SQL queries is faster to build and perfectly fine. A polished internal dashboard can wait until someone other than the founder needs it.
• Edge-case handling for volume you don't have yet. Build for the load you'll actually see in the first three months, not the load you hope to see in year two.
• Configurability. Hardcode the business rule. A settings page for a rule with one current value is speculative work.
• Multi-tenancy, if you don't have multiple tenants yet. This one is reversible later with real effort, but it's rarely the bottleneck to a first pilot.

What we never cut, on any timeline

• Authentication and authorization done properly. This is the one category where "fast and rough" creates liability that outlasts the MVP itself.
• A real data model. Schemas are expensive to unwind later; UI is cheap. We spend disproportionate time here even under a tight deadline.
• Payment and PII handling, if either is in scope. Compliance debt compounds faster than almost anything else in a codebase.
• A deploy pipeline that isn't a laptop. Even a minimal CI/CD setup pays for itself the first time a founder needs to ship a fix at 11pm without you.

Scope is a conversation, not a constraint you discover later

The timelines that go sideways are almost always the ones where scope got decided implicitly — a feature crept in during a Slack thread, nobody flagged that it doubled the estimate, and the 8 weeks quietly became 14. The fix isn't tighter discipline on our end alone; it's making the cut list visible to the founder up front, so "no" to a feature is a shared decision instead of a surprise in week 6.

That's the actual deliverable of week one on any MVP engagement: not code, but a scoped, written-down list of what's in and what's explicitly out — reviewed with the founder before a single architecture decision gets made.