LaunchPhase | MVP Development: How to Ship a Real Product in 90 Days

Continue exploring ideas in web design and beyond.

Most failed products are not badly built. They are precisely built versions of something nobody wanted, discovered after a year of development and a great deal of money. The purpose of an MVP is to reach that discovery in weeks rather than years, while it is still cheap to change direction. A minimum viable product is not a cheap product or an unfinished one. It is the smallest complete thing that lets real users get real value, so you can learn whether the value is real at all.

Find the Core Loop and Build Only That

Every product has one loop that delivers its central value. A user does something, gets something back, and comes back for more. Identify that loop in one sentence and treat everything outside it as a candidate for deletion. If your sentence needs an “and” you are probably describing two products. Choose one. The other can be phase two, once you know whether phase one matters to anybody.

The Ruthless Feature Cut

Write every feature you have imagined on a list. Then move each one into build, defer or delete. Most teams find that fewer than a third of their features belong in the first release. Cut settings and customisation and pick sensible defaults instead. Cut admin panels where a spreadsheet and a manual process will do for the first fifty users. Cut integrations beyond the single one your core loop genuinely requires, and cut onboarding flows, tutorials and gamification until you know the product is worth learning. Do not cut authentication, payments if you charge, or anything touching data security.

A Ninety-Day Structure That Works

Weeks one and two are discovery and specification — user interviews, the core loop defined, success metrics agreed and a written scope everyone signs. Weeks three and four cover user flows, key screens and a clickable prototype tested with a handful of target users. Weeks five through ten are build, delivered in two-week sprints with a working demo at the end of each. Weeks eleven and twelve cover testing, bug fixing, analytics instrumentation and a beta with real users before public launch. The structure works because it forces decisions early, when they are cheap.

Choosing a Stack You Will Not Regret

Pick boring, well-documented technology with a large hiring pool. An MVP is not the place to experiment with a framework three people understand, because the constraint that matters is how fast you can change direction next month. Use managed services for authentication, payments, file storage and email rather than building them. These are solved problems, and every hour spent reimplementing them is an hour not spent on the thing that makes your product different.

What to Do With the First Hundred Users

Launch is the beginning of the learning phase, not the end of the project, and the first hundred users are the most valuable research you will ever get. Talk to them individually, especially the people who signed up and then stopped, because churned users explain the product’s real weaknesses far more clearly than enthusiasts do. Watch session recordings of people using the core loop and note every hesitation. Resist the temptation to build every requested feature — requests are data about problems, not specifications for solutions.

Instrument Everything and Define Success Early

Decide before launch what result would justify continuing, what would justify pivoting, and what would justify stopping. Write the numbers down, because deciding afterwards guarantees you will interpret whatever happens as encouraging. Track activation, retention at seven and thirty days, and completion of the core loop. Vanity metrics like signups and page views tell you about your marketing, not your product. Retention is the only number that reliably predicts whether you have built something people want.

How much should an MVP cost?

Far less than a full product, but it is still real engineering. The main lever is scope — every feature you defer reduces cost and shortens the feedback loop that makes the investment worthwhile.

What if competitors copy my MVP?

They can copy features. They cannot copy what you learn from your users, and speed of iteration is a more durable advantage than secrecy for almost every early product.

Should my MVP be free or paid?

Charge if you intend to charge eventually. Willingness to pay is the clearest possible validation, and free users answer a different question than paying ones.

When should we stop calling it an MVP?

When retention and usage are stable enough that you are investing to grow rather than to validate. At that point the questions change from whether people want this to how many people want this.