Writing

An MVP in 60 to 90 days: a realistic plan, week by week

What a first version actually looks like from the inside: what happens in foundations, what the build weeks contain, what gets cut, and what you have at the end.

“MVP in 90 days” is a phrase that gets thrown around, and it is usually either a lie or a plan to ship something nobody can use. It can be true, but only if the first version is honestly scoped, and only if the weeks are spent the right way. Here is what the plan actually looks like from the inside.

Before the clock starts: foundations

The 60 to 90 days do not begin with code. They begin with four to eight weeks of foundations, and skipping this is the most common way a first version becomes a first year.

Foundations settle five things: who it is for and what they do today; the three or four flows that must work end to end; what is explicitly left out; the stack, chosen for the second version as much as the first; and the plan for the build, with a cost. You leave with a document you could take to any team. Most people take it to the team that wrote it, because by then the hard thinking is shared.

Weeks 1 and 2: the skeleton

The first fortnight produces something you can log into and click through, even though most of it does not work yet. Accounts, the main screens, the data model, deployment to a real address. It looks unfinished because it is. Its purpose is to make everything after it concrete: from now on every week changes a thing you can see.

This is also when design happens, inside the build rather than before it. Screens are drawn as they are built, with the real content, and changed when they are used.

Weeks 3 to 6: the flows, one at a time

Each of the three or four flows from foundations is built end to end, in order of importance, and put in front of someone real as soon as it works. Not a demo to the founder; a user doing the actual thing. A parent checking a schedule. A seller listing an item. An admin approving a request.

The feedback from those first uses reshapes the next flow. That is the point of building in the open. A plan that survives contact with users unchanged was not a plan; it was a guess that got lucky.

Weeks 7 to 10: the parts that make it real

The unglamorous half. Payments, if there are payments. Notifications that people actually want. The admin your team runs it from, which is often the difference between a product and a prototype. Permissions. Backups. The error states that happen when the network drops in a lift.

A first version that skips this half looks finished and falls over in the first week of real use. One that includes it is smaller on the surface and much stronger underneath.

Weeks 11 to 13: launch, quietly

A launch is not a day; it is a fortnight of real users at increasing volume while the team watches. The first ten users find things nobody could have predicted. The next fifty confirm which of those matter. By the end, the product has been through enough real days that you trust it.

What gets cut, and why that is good

Everything that was on the “later” list in foundations stays there. Along the way, more joins it: the feature that seemed essential and that no user has asked for; the integration that can wait until there is something to integrate; the settings page. A first version with fewer features that real people use every day is worth more than a full one that is merely finished.

What you have at the end

A product in real use, with real users telling you what version two is. Code in your repository, accounts in your name, a system that can be deployed without a particular person. A team that knows your users by name. And a list, written down, of what comes next, in the order users have already voted for.

When 90 days is not honest

If the first version genuinely needs a live video classroom, a two-sided marketplace and a mobile app to be usable, it is not a 90-day product, and anyone who says it is will either pad the price or deliver something hollow. The honest move is to find the smaller product inside it that a real user would still pay for, ship that, and let it earn the rest. That is what foundations are for, and it is why we insist on them.

The long version of how we think about the first version is product foundations: what to build in your first 60 to 90 days. If you have an idea and a date, tell us both.

Have something
worth building?

Tell us what it is, in a few lines. We'll say honestly whether we're the right people for it, and what a small first step would look like. No decks, no discovery-call theatre.

Zofwe · Product studio · Kerala, India · Working with teams anywhere