Build a SaaS Product in 90 Days: Narrow, Honest, Shipped

A SaaS product in 90 days is not a marketing claim, it is a discipline. The deadline forces decisions that would otherwise take months. Three days arguing about pricing becomes three hours. A four-week roadmap workshop becomes four days. Whatever does not fit gets cut. That is not lack, that is focus.

The hard part is not the plan, it is the cutting. Shape Up by 37signals describes the same pattern: small fixed cycles that force real decisions, not long sprints that promise everything.

What you take away:

• The 90-day cut: what stays in, what stays out.
• The crew: three people plus agents.
• The weekly logic: what must ship by week 4, 8, 12.
• The self-deceptions that turn 90 days into nine months.

The thesis

You build a SaaS product in 90 days by cutting the problem narrow, running a crew of three plus AI agents, and shipping in fixed weekly blocks. Not everything you want, but the part people pay for.

What must make the 90-day cut?

Four things must make the cut: a clearly bounded problem, a paid pilot setup, the minimum function that solves the problem, and onboarding that works without a call. Everything else is phase two. Phase two starts on day 91.

Concretely: not "we build a platform for marketing automation", but "we solve the recurring pipeline forecast friction between marketing and sales for DACH mid-market teams". The narrower the cut, the more realistic the build.

The paid pilot is the most important of the 4 items. It forces you to ask the pricing question before the build, not after. Whoever won't pay a pilot fee won't buy a licence later. How to sharpen the cut in words is covered in product positioning for B2B.

What does the crew look like?

Three people: product decider (founder), engineering lead, designer with frontend skill. Plus four to six agent roles: spec writer, QA, release-notes writer, customer interview synthesiser, marketing asset operator. No SDRs, no account management, no project manager.

This is not a small variant of an enterprise team. This is the natural shape when AI agents carry routine tasks. Three instead of thirty is not a slogan, it is a question of which tasks remain.

The agent roles are not decoration. The spec writer turns every interview into a testable ticket. The QA agent checks every build before a human looks at it. How this way of working comes together is what I show in From Vibe Coding to Agentic Engineering.

How is the weekly logic structured?

You work in three 30-day blocks: discovery, build, activate. Discovery (week 1 to 4) clarifies problem, ICP and pricing with 10 to 15 interviews. Build (week 5 to 8) ships the minimum function plus onboarding. Activate (week 9 to 12) lands 3 to 5 paying pilots and an honest release.

Short demo every Friday, decision on the cut every two weeks. If you cannot demo on Friday, you cut wrong on Monday.

The discovery interviews are not a formality. They produce the ICP, the ideal customer profile: the companies where the problem is most expensive. Without that profile you build for everyone from week 5, and therefore for no one. With it, you know exactly who to call in week 9.

What are the most common self-deceptions?

Three repeat. First: "we need a beta with a hundred users". Wrong, you need three paying users with a real problem. Second: "we build it ourselves, cheaper than buying a tool". Rarely right in 90 days. Third: "we have to align on branding first". Branding comes from shipping, not from a workshop.

What does NOT belong in the first 90 days?

Out of scope: SSO, integrations for logos you don't have, admin panels, the second persona, role and permission concepts, and anything labelled "enterprise-ready". None of it wins you the first paying pilot. All of it eats weeks.

SSO is the best example. Single sign-on sounds mandatory. In truth it answers a procurement department you're not even talking to yet. Build it when a paying customer makes it a condition. Before that, it's procrastination with a clear conscience.

The same goes for integrations. One integration per real pilot is defensible. 5 integrations for logos on a wish list are 4 too many. And an admin panel for 3 pilot customers is replaced by database access and an hour of manual work per week.

The most expensive item is the second persona, a second user role with needs of its own. It quietly doubles everything: second onboarding, second pricing logic, second roadmap. One persona, one problem, one price. The rest is day 91.

Where do the first paying pilots come from?

From your network, not from ads and not from outbound, meaning cold approaches to strangers. The first customers are design partners: companies that know the problem, trust you and pay for it. Small in amount, serious in commitment.

Mark Roberge, HubSpot's first sales chief, describes this as a phase of its own in The Science of Scaling. According to Roberge, the first customers come through the personal network and through referrals. The goal of this phase is learning, not revenue.

His second point is uncomfortable: price for commitment, not for profit. Free attracts the uncommitted, says Roberge. A nominal fee beats free, because only an invoice forces an honest yes or no. A pilot that costs nothing delivers no signal.

As the first learning goal, Roberge names roughly 20 customers. That's more than fits into 90 days, and that's fine. The 3 to 5 pilots from the activate block are the start of that learning curve, not its end. Roberge's experience comes from US SaaS. As a reference point it still works, in DACH too.

The hard comparison: 90 days versus 9 months

A nine-month project with twelve people in Switzerland roughly costs between CHF 800'000 and 1'500'000, depending on seniority. A 90-day project with three people plus agents costs a fraction and answers the central question early: will anyone pay for this? If no, you save eight months. If yes, you have eight months of lead.

This is not speculation. CB Insights lists "no market need" as the most common reason for startup failure. A 90-day cut tests exactly that question before it gets expensive.

Day 91: which base comes next?

The second one: product-market fit, PMF for short, the proof that customers pay and stay. Stijn Hendrikse describes the path in T2D3 as running the bases: first base MVP, the first sellable version, second base PMF, third base scaling. And you cannot skip bases.

Skip anyway and, according to Hendrikse, you will have to go back and repair. That matches what I see. A team that scales sales on day 91 usually scales a product nobody wants to keep yet. The 90 days get you to first base. No further, but honestly there.

Hendrikse makes PMF measurable with a checklist of 10 milestones. The last 3 are the hardest: 10 paying customers, 10 public testimonials from paying customers, 10 new paying customers through referrals. Only then, he says, is PMF reached. That's the honest finish line after the 90 days.

His milestones are experience from his own client work, not laws of nature. But as a checklist they're useful, precisely because they're uncomfortable. They stop you from confusing "we launched" with "we have a business". More craft for this phase lives in the software product management hub.

Outro

✅ What works. Narrow cut plus small crew plus fixed deadline ships. Every time the discipline holds.

❌ What does not. Trying to fit every stakeholder wish into 90 days. That is phase two, not phase one.

⚠️ Warning. "We just extend by two weeks" is the start of nine months. Cut before you extend.

The deeper point: a 90-day cut is not a speed trick, it is a truth trick. The deadline forces the decisions you would never make without one. That is where we started, with cutting instead of building.

If you want to see what a 90-day plan looks like in detail, read our process.

Frequently asked questions

Can three people really do it?

Yes, when the cut is narrow and agents carry the routine tasks. Adding people in 90 days does not help, it slows decisions.

What if the problem is bigger?

Then you cut. A bigger problem can almost always be split into a smaller paid sub-problem. If not, it is not a SaaS problem.

How much does it cost?

In Switzerland roughly CHF 150'000 to 350'000 for 90 days with three people plus an agent stack. A fraction of a classic project.

What if day 90 has no pilot?

Then discovery was wrong. Stop, write down honestly what you learned, and consciously decide whether to fund phase two.

When is a bigger setup justified?

Once three paying pilots confirm demand and the bottleneck is demonstrably engineering capacity, not decisions. Before that, more headcount accelerates the wrong path.