Building an MVP in 90 days.

Define the one thing it must prove

An MVP exists to test a specific uncertainty. Before any technical planning, write down the single question the build must answer.

It might be whether people will complete a particular workflow, whether they will pay, or whether a process can be automated reliably enough to trust. Everything that does not serve that question is a candidate to cut, and you will need that filter constantly once the build starts.

If you cannot state the question in one sentence, you are not building an MVP. You are building version one of a product, which is a different scope and a different timeline.

What to cut, specifically

• Admin interfaces - use database access and scripts for the first months
• Granular permissions - two roles is nearly always enough initially
• Password reset flows - magic links avoid an entire subsystem
• Onboarding wizards - a well-written email does the same job at this stage
• Analytics dashboards - export to a spreadsheet until the questions stabilise
• Native mobile apps - a responsive web application first, unless mobile is the hypothesis

A sequence that works

Weeks one and two are discovery and setup: the domain model, the primary workflow drawn end to end, repository, CI and a deployed skeleton in a real environment. Deploying something trivial in week one removes an entire category of late surprise.

Weeks three to eight are the core loop. Build the single workflow that answers your question, end to end, before adding anything beside it. A narrow product that works completely is testable. A broad product that is half-built everywhere is not.

Weeks nine and ten are the supporting essentials: authentication, payment if it is part of the hypothesis, and error handling on the paths users will actually hit.

Weeks eleven and twelve are hardening and launch: real data, load, the error cases, and the instrumentation you need to learn anything from the launch at all.

Decisions that cause overrun

Three decisions account for most ninety-day plans becoming five months.

Choosing unfamiliar technology because it is interesting. An MVP is the wrong place to learn a new framework, and the cost shows up in week seven rather than week two.

Building for scale you do not have. Sharding, microservices and elaborate caching before you have users is time spent on a problem you may never get.

Designing screens before the workflow is settled. Detailed design on an unstable workflow gets rebuilt, and the rebuild is rarely budgeted.

Instrument it before you launch

An MVP that ships without instrumentation cannot answer the question it was built for, which makes the whole exercise close to pointless.

Before launch, know how you will measure the workflow: where users start, where they stop, how long it takes and what they do afterwards. Error tracking, structured logging and basic funnel analytics take about two days to set up and determine whether you learn anything at all from the launch.