The 90-Day Path From Idea to a Shipped MVP

Ship it in 90 days by treating the deadline as the one number you never move. Everything else — feature list, polish, architecture — flexes around it. The founders who stall are not slow builders; they are builders who keep widening the scope until the finish line disappears. This is a week-by-week plan to keep that from happening.

Why 90 days, and not “when it’s ready”

“When it’s ready” is not a plan. It is an open loop that expands to fill whatever time you give it, because there is always one more thing that would make the product a little better. A fixed 90-day window forces the only question that matters early: what is the smallest thing that delivers real value to one real person?

The date is not arbitrary pressure. It is a design constraint. When the calendar is fixed, scope becomes the variable you actively manage — and managing scope is the entire job of an early product.

Perfect is not the opposite of shipped. Perfect is the most convincing excuse a founder gives themselves for not shipping.

Weeks 1–2: Define one user, one job, one moment

Before a line of code, write down three things and pin them where you will see them daily:

• One user. Not a segment — a person specific enough to picture. “Solo Shopify sellers doing under $20k a month,” not “e-commerce businesses.”
• One job. The single task they are hiring your product to do. If you list three, you have three products and no MVP.
• One moment of value. The exact second the user thinks “oh, this is useful.” Your whole build exists to get them to that moment as fast as possible.

Then run the deletion pass. List every feature you imagined and cut anything that does not directly move the user toward that one moment. This is uncomfortable and correct.

Weeks 3–4: Map the core loop and fake the rest

Every product has a core loop — the repeated action that creates and delivers value. Map yours as a literal sequence of steps. That loop is the only thing you are truly building.

Everything around it can be faked in the MVP:

• Payments? A Stripe payment link, not a billing system.
• Onboarding? A Loom video and a Calendly link, not a product tour.
• Admin and ops? A spreadsheet and manual work behind the scenes. Do things that don’t scale on purpose.

The discipline here is separating what is hard to replicate (your actual edge) from what is just plumbing (everything users expect but no one chooses you for). Build the first. Fake the second.

Weeks 5–8: Build the hard part, badly

Now you build — but only the differentiating core, and you let it be ugly. Use the boring, familiar stack you already know. Skip the abstractions you would need at scale; you do not have scale, you have a hypothesis. Hardcode. Copy-paste. Leave TODOs.

A technical founder’s instinct is to build something they would be proud to show another engineer. Resist it. The MVP is not a portfolio piece; it is an instrument for learning whether anyone wants this. Clean architecture protects code you have proven people need. You have not proven that yet.

Two rules keep this phase honest:

1. If a feature is not part of the core loop, it does not get built this month. Write it on a “later” list and move on.
2. Ship to yourself daily. Use your own product every day. The bugs you trip over are the bugs your users would have quit over.

Weeks 9–10: Put it in front of ten real users

By day 60 the product should be in the hands of ten people who match your one-user definition — not friends being polite, actual target users. This is the phase most founders skip because it is scary, and it is the phase that determines whether the last month is spent well.

Watch them use it without helping. The moments where they hesitate, misread a label, or ask “wait, how do I…” are your real backlog. What you thought was confusing rarely matches what is confusing.

Collect two signals above all:

• Did they reach the moment of value? If not, the loop is broken and nothing else matters yet.
• Did any of them come back on their own? Unprompted return is the earliest honest sign of retention.

Weeks 11–12: Fix the right things and launch

Now — and only now — you polish. But you polish against evidence, not taste. Every fix in the final two weeks should trace to something a real user did or said. Rank issues by how many users hit them and how badly, and work down that list until the calendar runs out.

Launch on day 90 even if it is imperfect. It will be imperfect. A live product with ten users teaching you what to build next beats a beautiful one that has never met a customer. The MVP was never the destination — it is the fastest possible way to earn the right to build version two.

The one-line version

Fix the date, shrink the scope, fake the plumbing, build the edge, and get it in front of ten real people before you fall in love with your own polish. Do that, and 90 days is enough.