How to ship a SaaS MVP in 90 days without cutting the wrong corners

Ninety days is enough to ship a real SaaS product that people pay for. It is not enough to ship the product you have in your head, and the difference between those two things is the entire discipline.

We have run this timeline enough times to know where it breaks. It is almost never engineering capacity. It is scope that expands quietly, and decisions that take eight days when they should take one.

Define done before you define features

Write one sentence: “This is finished when a customer can ___ without us helping them.” Everything that does not serve that sentence is version two. Everything.

A useful test: if a feature disappeared overnight and no paying customer would notice within a week, it was not MVP scope. Founders find this exercise uncomfortable, which is precisely why it works — it forces the ranking that would otherwise happen implicitly, in week ten, under pressure.

Weeks 1–2: decisions, not code

The first fortnight is architecture and flows. Decide the tenancy model, the permission model, and the payment model. These three are structural: changing any of them in week nine is not a change, it is a rebuild.

Map the one workflow that matters end to end, including the empty states and the failure cases. Design the screens for it. Get them approved. Two weeks spent here reliably saves four weeks later, and it is the part clients are most tempted to compress.

Weeks 3–8: build the spine

Authentication, tenancy, the core workflow, and billing — in that order. Billing goes in early, not last, because it touches everything and because a product that cannot take money is a demo.

Ship to a real staging environment from week three and use it yourself daily. Software that only exists on a developer's machine accumulates surprises. Software you use every day surfaces them while they are still cheap.

Weeks 9–11: make it survivable

This is the phase that gets sacrificed when things slip, and it is the phase that determines whether launch is calm or awful.

• Error monitoring: you should know about failures before a customer emails you.
• Automated backups: and one test restore. An untested backup is a belief, not a backup.
• Deployment pipeline: if shipping a fix takes more than a few minutes, you will avoid shipping fixes.
• Onboarding: the first five minutes decide whether a signup becomes a customer.
• Documentation: written as you go, so support is not a person's memory.

Week 12: launch small, deliberately

Open to ten users you can talk to, not a thousand you cannot. The first fortnight of real usage will teach you more than the previous twelve weeks of internal opinion, and it is far easier to fix things for ten people than to apologise to a thousand.

Keep the second version's roadmap empty until those ten have used it. What they actually struggle with is almost never what the team predicted.

The four things we never cut

Deadlines force trade-offs and that is healthy. These four are not available as trade-offs, because each one costs multiples to add later.

• Data isolation between tenants: the single most expensive thing to retrofit, and the one with legal consequences if it goes wrong.
• Automated deploys: manual releases guarantee that the urgent fix is also the risky one.
• A migration path for the database: you will change the schema. Plan for it in week one.
• Somebody's name against every decision: ambiguous ownership is what turns a three-day delay into a three-week one.

What actually causes overrun

In our experience it is rarely technical. It is a stakeholder who joins in week six with opinions, content that arrives three weeks late, a payment provider account that took eleven days to verify, or a decision nobody felt authorised to make.

Name one decision-maker, give them a same-day response commitment, and get every account and credential created in week one. That alone is worth more to the timeline than any framework choice.