How we ship a SaaS MVP in twelve weeks
Founders ask us the same thing on the first call. How fast can we get a real product in front of real users? Our honest answer is twelve weeks, and here is the exact plan we follow to make that happen.
An MVP is not a smaller version of your dream product. It is the shortest path to learning whether people will pay for the thing you are building. We have run this play with founders like Tradeline, who came to us with a spreadsheet and a waitlist and left with ten thousand users in a single quarter. The trick is not speed for its own sake. It is knowing what to leave out.
/ Table of contents:
Week one, the plan
We start by getting brutally clear on one question: what is the single thing this product has to do well for someone to pay for it? Everything else waits. In the first week we sit with the founders, map the core user journey, and write down the features that are in scope. Just as important, we write down what is out of scope, so nobody is surprised in week eight. By Friday we have a firm timeline, a feature list everyone has signed off on, and a shared idea of what winning looks like.
An MVP is not about building less. It is about building the right thing first, then earning the right to build more.
/ Elena Petrova
That first week feels slow to founders who are itching to see something on screen. We get it. But the hours we spend agreeing on scope are the cheapest hours in the whole project. A clear plan up front is what lets us move fast later without wandering off course or rebuilding the same screen three times.
Weeks two to four, design and core
With the plan locked, two tracks run side by side:
- Product design
- We design the core screens in Figma, not in code.
- Founders click through a real prototype before we build it.
- The core engine
- Engineers set up accounts, the database, and the data model.
- We build the one feature the whole product depends on first.
- Decisions, written down
- Every choice that affects scope gets logged.
- So three weeks later nobody is guessing why we did it.
Weeks five to ten, build
This is the long stretch where the product takes shape. We work in the open, with check ins you can count on. Here is what fills those weeks:
Billing and accounts
We wire up sign up, login, and payments early, usually with Stripe, because a product that cannot take money is not a business yet. Getting billing in while the codebase is small saves a lot of pain later.
The dashboard
Most SaaS products live and die by their main dashboard, so this is where we spend real care. We build the screens users will touch every day, then sit with the founders and use them like a customer would.
Weekly demos
Every Friday we show working software, not slides. Founders click around the live build, tell us what feels off, and we adjust on Monday. No surprises, no big reveal at the end.
Weeks eleven and twelve, polish and launch
Polish. We fix the rough edges, tidy the copy, and make the product load fast on a cheap phone with a weak signal. Speed is a feature.
Real data. We invite a handful of friendly users in, watch where they get stuck, and patch the spots that trip them up before the wider launch.
Launch. We ship it to live users with billing on and monitoring in place. Tradeline hit ten thousand users in their first quarter and raised a seed round on the live product.
After launch
Twelve weeks gets you a live product, not a finished one. The tools we lean on, from design files to shared roadmaps, keep the work visible once real users arrive. That is when the real work begins. A good MVP gives you three things:
- Proof that people will pay, so you can raise on something real;
- A live product you own outright, every line of code and every account;
- A roadmap shaped by usage, so the next features earn their place.
Final thoughts
Twelve weeks is not a magic number. It is what happens when you cut scope honestly and build in the open. If you are a founder sitting on an idea, here is my advice:
- Pick one thing: Find the single feature people will pay for and ship that first;
- Stay close: Get on every weekly demo and tell us what feels wrong early;
- Launch sooner: Real users teach you more in a week than planning does in a month.
