How We Scope a SaaS MVP That Ships in 8–12 Weeks
{ BLOG DETAILS }
How we turn a rough product idea into a signed scope, a fixed estimate, and working software inside a quarter
Introduction
Most MVPs miss their date for the same reason: the scope was agreed in a conversation rather than in writing. Here is the process we run before a line of code is written — what we ask, what we deliberately leave out, and why a fixed estimate is possible once the tenancy, billing and access model are settled up front.
Delivery
June 1, 2026
JHJunaied Hossain
Share Article
Start With the Deadline, Not the Feature List
The first question we ask is never “what should it do?” It is “what has to be true on launch day, and who is waiting for it?” A feature list expands to fill whatever time you give it. A deadline with a named audience forces the trade-offs into the open while they are still cheap to make.
From there we work backwards: the smallest set of capabilities that lets a real user complete a real task end to end, and everything else parked in a written “not in v1” list the client signs off on too.
Settle the Expensive Decisions First
Tenancy, access control and billing are the three decisions you cannot cheaply reverse. How isolated is each customer’s data? Who can see what, and who grants that? Does the plan gate features, seats, usage, or some combination? We answer those in week one, on paper, before any screen exists.
Everything downstream gets easier once they are settled. Schema, API surface, admin tooling and the deployment pipeline all follow from those three answers — which is exactly why a fixed estimate is possible after discovery and dishonest before it.
Ship in Two-Week Slices
Every fortnight something real lands on staging. Not a status deck, not a Figma walkthrough — software the client can click. That cadence is the whole point: it means a wrong assumption costs two weeks to correct instead of surfacing at the end, and it gives the client a genuine chance to redirect us while redirecting is still cheap.
Say No Before Invoicing, Not After
If a feature is not worth what it costs, we say so during scoping rather than after the client has paid for it. That single habit is why the 8–12 week number holds: the MVPs that slip are almost never slowed by engineering, they are slowed by a feature nobody was willing to cut.
“An estimate you cannot defend is not an estimate, it is a wish. Do the architecture work first, then quote — and be willing to tell the client which half of their feature list is not worth building.”
Conclusion
A quarter is enough time to put a real product in front of real users, provided the expensive decisions are made in week one and the scope is written down rather than remembered. Discovery, a signed scope, two-week slices, and an honest no where it is warranted — that is the whole method, and it is why we can put a date on it.
