Six weeks is enough time to build something real and not enough time to build something bloated — which is exactly why we like it as a constraint. The hard part of an MVP is never the engineering. It is deciding, honestly, what the product does not do yet.
Start from the one job the product must do
Every product we scope begins with a single sentence: "A user comes here to ___." If you need a paragraph, the scope is too wide. Everything that does not directly serve that one job goes on a later list — a real list, written down, so the founder trusts that it is deferred, not forgotten.
Cut ruthlessly, then cut again
- One user role at launch, not four. Admins can use the same screens for now.
- One happy path, instrumented, before any edge case.
- Buy or embed anything that is not your differentiator — auth, payments, email.
- Manual back-office over an admin panel nobody has designed yet.
Where AI earns its place in an MVP
AI is worth including in an MVP only where it is the differentiator — the thing that makes the product feel impossible without it. If the AI is a nice-to-have, defer it; it adds cost, latency, and failure modes you do not want to debug in week five. When it is the core, build the seam we describe in our AI features piece so you can iterate on prompts and providers without destabilising the launch.
Ship, watch, decide
The point of an MVP is not to be finished — it is to put something in front of real users and learn what to build next from behaviour instead of opinion. We hand over a product that is instrumented from the first click, so the roadmap after launch is written by users, not guesses.
That is the whole method: one job, ruthless cuts, AI only where it is core, and instrumentation so the next six weeks are informed. It is not glamorous, but it is how founders get to a real product without burning the round.