From idea to MVP in six weeks: how we scope first versions

The difference between an MVP that ships in six weeks and a project that drifts for a year is almost never engineering speed. It is decided earlier, in scoping, before the first line of code exists.

Start from the riskiest assumption

Every new product rests on one assumption that, if wrong, kills it. Usually it is not "can this be built" but "will anyone change their behaviour to use it". The first version exists to test exactly that assumption and nothing else. Write the assumption down in one sentence. Every feature then has to justify itself against it.

The one-flow rule

A six-week MVP contains one complete user flow: the path from "stranger arrives" to "value delivered". For a marketplace that might be: browse, request, get matched, pay. Admin panels, settings pages, notification preferences and the second user type all wait. They are version-two problems, and version two only exists if version one proves the assumption.

• One user type, one flow, one platform (web first, app later, almost always).
• Standard building blocks for login, payments and email. Custom code only where your idea is different.
• A deadline that is a date, not a feeling. Scope bends; the date does not.

Boring technology wins

An MVP is the wrong place for experimental tech. We build first versions on the most boring proven stack that fits, because every exotic choice adds risk to a project whose whole point is to reduce risk. The interesting technology can come later, funded by a product that works.

What week six looks like

At the end of the sixth week there is a product with real users in it, analytics that show what they do, and a short list of what to build or kill next. Sometimes the assumption fails. That is not a failed project; that is the cheapest possible way to learn it. The expensive way is the same lesson after a year of building.