Twelve weeks for an MVP is a lie I tell myself every January. Then I build one anyway, and the lie holds up only because I am ruthless about what those twelve weeks contain. If you want to build a SaaS MVP in 12 weeks, the calendar is not your real problem. Your definition of done is.
I have shipped this way more than once. BookBed went from an empty repo to paying-customer-ready on a timeline like this, and Callidus did too, on a harder domain. The roadmap below is what actually happens when a plan survives contact with real users and real billing, not the version that looks tidy on a pitch deck.
Most "12 week" SaaS MVP plans are fiction before week one
Most agile SaaS MVPs are six months disguised as twelve weeks, because nobody counts the pre-coding spec phase.
The trick the timeline plays on you is simple. The countdown starts the day you write code, but the product started forming weeks earlier in Figma files, Notion docs, and three calls where a founder quietly changed the core flow twice. That work is real engineering. It just never lands on a sprint board, so when someone says twelve weeks, they mean twelve weeks after the part nobody tracked.
You have felt this if you have ever quoted a timeline and watched it evaporate. The build was fine. The thing that ate the calendar was deciding what to build while already building it. A SaaS MVP that changes shape in week four was never behind schedule. It never had a schedule to begin with.
So I moved the spec out of the build window entirely. Week 0 is not week one. It is a separate, funded, deliverable phase, and I do not start the clock until scope is locked in writing. I use a scope template so the lock is something concrete you can point at later when feature requests start arriving mid-build, which they always do.
Week 0: lock the spec before you touch code
Week 0 produces three artifacts: a one-page scope with explicit non-goals, a data model sketch, and a clickable flow for the single feature the product cannot exist without. Non-goals matter more than goals here. Writing down what you are not building in v1 is the only thing that keeps week six from quietly becoming week sixteen.
The single-feature exercise is the one founders resist most. Every product owner believes their MVP needs five pillars. It almost never does. There is one job the user is hiring the software to do, and the other four are context around it. If you cannot name that one job in a sentence, you are not ready to start the clock, and no amount of velocity later will rescue a fuzzy core.
This is also where you cost the thing honestly. If you have never priced a build before, run the numbers through an app cost estimator so the founder and the engineer are looking at the same reality. A surprise about money in week eight is worse than almost any technical surprise, because it arrives when you have the least slack to react to it.
Weeks 1-2: auth, the tenant model, and a deploy that deploys
Two weeks, three things that have to be boring and correct: authentication, the multi-tenant data model, and a deployed hello-world the founder can open on their phone.
The tenant model is the decision you cannot cheaply undo. Get the boundary right now, whether that is row-scoped access with RLS on Postgres or path-scoped rules on Firestore, because retrofitting tenant isolation onto a live database with real customer data is its own multi-week project, and a scary one. Every query you write after week two assumes this boundary. If it is wrong, you are not fixing a bug later, you are migrating production. If you are still choosing tools, my opinionated SaaS MVP stack exists precisely so you do not spend two of your twelve weeks comparing frameworks instead of building.
Authentication gets the same treatment. Use a provider, wire up the roles you sketched in Week 0, and resist the urge to hand-roll session logic to save a dependency. The hours you save there get repaid with interest the first time a JWT refresh edge case locks a paying user out on a Sunday.
A deploy that deploys. I mean it as its own goal. CI to production from day three means every later week ends with something real, not a branch nobody has run outside localhost. The first time you wait until week ten to deploy, you discover that the gap between works-on-my-machine and works-in-production is exactly the gap you have no calendar left to close.
Weeks 3-6: the core, where a SaaS MVP in 12 weeks lives or dies
These four weeks are the product. Everything before was scaffolding, everything after is plumbing, and this is the part a user would actually pay for. CRUD on your core entities, the business logic that makes the app yours, and enough UI that one person can complete the main job from start to finish without a guided tour.
Protect these weeks like they are the only ones that exist, because in a sense they are. Meetings, nice-to-have polish, and the second and third features all try to colonize this block. Say no. The discipline that makes a twelve-week build possible is almost entirely the discipline of refusing good ideas until v2.
The core is also where the calendar bites back, and it rarely announces itself politely. Here is how that went on Callidus.
On Callidus, week 8 was the wall. The face-mapping editor was 'done' but rotating the head in the canvas leaked memory on every interaction. Spent two days bisecting react-konva updates before realizing my own ref cleanup was wrong. Lost the week. Shipped the rest in time only because I'd over-bought weeks 1-6.
Actually, let me back up, because the lesson is not "canvas libraries are hard." The lesson is that I had slack to spend. I had finished the boring weeks ahead of schedule, so when one feature detonated, the buffer absorbed it without moving the launch. A twelve-week plan with no buffer is a six-week plan you have not finished lying to yourself about yet.
Weeks 7-9: billing, email, and the admin you forgot
Billing is where MVPs quietly slip. Stripe is not hard, but the edges multiply faster than you expect: trials, proration, failed charges, dunning, and on Callidus, Stripe Connect onboarding state for each clinic before it could take a payment. Wednesday at 11pm the Connect webhook started returning 500s because I had assumed an account was always fully onboarded before its first charge. It was not. One bad assumption, one evening gone, and a lesson about never trusting the happy path in a payments flow.
Email and an admin view round out these weeks. Transactional email for receipts, verification, and password resets, plus a minimal internal admin so you can fix customer data without a raw database client open on your lap during a support call. Neither is glamorous. Both are the difference between a demo and a product someone trusts with their business.
Budget more time here than feels reasonable. Money flows and account states have a way of generating edge cases that pure CRUD never does, and every one of them is the kind of bug that loses trust rather than just annoying a user.
Weeks 10-11: hardening and the security pass
Now you slow down on purpose. Observability so you find out about errors before your users tell you, a real security pass on the tenant boundary you set in week one, rate limits on anything that touches money or auth, and the long tail of edge cases you flagged and deferred during the core build.
This is the phase founders most want to cut, because the product already looks finished. Do not let them. The hardening weeks are the entire reason the beta does not become a public incident with your earliest customers watching. Looking finished and being safe to use are different states, and the distance between them is measured in exactly these two weeks.
Week 12: ship the closed beta
Small, on purpose. A handful of real users, a feedback channel you actually read, and a written list of what you already know you will fix. Not a launch. A first contact, where the goal is learning, not applause.
So what does your week 8 look like?
Every realistic roadmap is really a bet about where your week will go sideways. Mine went sideways in a canvas renderer. Yours will go sideways somewhere else, and the only defense is buffer you bought early by making the easy weeks genuinely easy instead of padding them with scope.
Before you commit to a date, do one thing this week: write the non-goals for your v1 and price the build honestly. If you cannot name what you are refusing to build, you do not have a twelve-week plan yet, you have a wish with a deadline attached. So here is the question worth more than any roadmap: what is the one feature your product cannot launch without, and what are you willing to cut to protect it?