The most useful thing about shipping a SaaS MVP in nine weeks isn't the speed. It's that the deadline does your prioritization for you. When there's plenty of time, every feature has a reasonable case and the scope quietly grows until the thing never ships. Nine weeks removes that luxury. You can't build everything, so you're forced to answer the only question that matters early: what is the smallest version of this that's genuinely worth using?
This is a short post-mortem on a recent v1. The headline lesson surprised even us: the features we deferred shaped the product more than the features we built.
The constraint that forces clarity
A nine-week deadline isn't a stunt. It's a forcing function. It converts vague aspiration into a series of concrete trades, each phrased the same way: if we build this, what doesn't get built? Suddenly "it would be nice to have" stops being a free addition and starts costing something visible. Most scope creep doesn't survive that question.
The discipline isn't moving fast. It's deciding fast, and then protecting the decision. A deadline gives you both — but only if you treat the cut list as seriously as the build list.
What we built: the spine
We built only the spine — the shortest path through which a real user gets the core value the product exists to deliver. One primary workflow, end to end, working properly. Not five workflows at 60%, but one at 100%. A user could sign in, do the main job, and get a real outcome. Everything that wasn't on that path was a candidate for the cut list.
That sounds obvious written down. In practice it's hard, because every adjacent feature feels load-bearing when you're staring at it. The discipline is asking whether the product delivers its core value without it. If yes, it waits.
What we cut, and why
The cuts are the interesting part, because each one was a deliberate trade rather than an oversight.
We didn't build authentication — we rented it. Auth is a tar pit. Password resets, session handling, social login, account recovery, the security edge cases you don't think of until they bite — it can quietly eat weeks and it's a solved problem. We used a managed auth provider instead of building our own. It cost a small monthly fee and saved an enormous amount of time and risk. Building your own auth for an MVP is almost always the wrong call: it's high-effort, high-risk, and adds zero differentiation. Nobody chose your product because of how you stored passwords.
We cut the admin dashboard. For v1, "admin" was us, running queries directly against the database. A polished internal dashboard is real work that serves a handful of internal users. It can wait until there are enough of those users for the manual approach to hurt.
We cut configurability. Every "let the user customize this" is a fork in the code and a multiplier on testing. v1 made opinionated defaults and shipped them. You can always add flexibility once you know which knobs people actually reach for — and you'll usually discover it's far fewer than you'd have guessed.
We cut the second and third integrations. The product connects to other tools, and it was tempting to support several from day one. We shipped one — the one the earliest users needed most — and left hooks for the rest. One working integration teaches you more than three half-finished ones.
An MVP isn't a smaller version of the product. It's the spine of the product, built well, with everything non-essential consciously postponed.
The cut we'd reconsider
Not every cut was right, and it's worth being honest about that. We under-invested in error states and empty states — the screens a user sees when something goes wrong or when they're brand new with no data yet. Those felt like polish, so they got deferred. But they're the moments that shape a first impression most, and a confusing empty state can lose a user before they ever reach the value. If we ran it again, a slice of the polish budget would move earlier, specifically to the first-run experience.
The lesson isn't "cut less." It's that not all polish is equal. Polish on a feature a user might reach next month can wait. Polish on the first five minutes can't.
How we sequenced the nine weeks
Speed came less from working harder than from ordering the work correctly. The shape of the nine weeks mattered more than any single sprint inside it.
The first stretch was deliberately not about building — it was about deciding. We defined the single spine workflow and wrote the cut list explicitly, on paper, so that "not now" decisions were made once and didn't get relitigated every time a new idea showed up. Most projects skip this and pay for it later, when scope creeps back in one reasonable-sounding feature at a time. A written cut list is a surprisingly powerful tool: it turns every future "can we just add" into a visible trade against something already decided.
The middle stretch was about getting the spine working end to end as fast as possible, even ugly. The priority was a complete path a real person could walk, not a polished fragment. An end-to-end flow that looks rough is far more valuable at that stage than a beautiful screen that leads nowhere, because only the complete path tells you whether the core idea actually holds together.
The final stretch was for the polish that mattered and the integration that mattered — and nothing else. This is where discipline gets hardest, because by then you can see the product and the temptation to add "just one more thing" is strongest. Protecting the cut list at the end is the whole game. The features that kill timelines are rarely the ones planned at the start; they're the reasonable-sounding additions that sneak in during the last two weeks, when everyone's excited and the deadline still feels far enough away to absorb them.
The sequence — decide, build the spine, polish what matters — is what made nine weeks realistic. Reverse any two of those and the same scope takes twice as long.
The real takeaway
An MVP is a sequencing decision, not a quality decision. The goal was never to build a worse product — it was to build the right part first, build it properly, and put it in front of real users early enough to learn from them. Everything we cut, we cut on purpose, and most of it we'd cut again.
The teams that struggle with this aren't the ones who build too slowly. They're the ones who can't bring themselves to cut, so they ship late, or never. Working software in front of real users beats a complete plan every time. Nine weeks didn't make the product smaller. It made us decide what it was actually for.