Eight weeks is roughly 40 working days. That sounds like a lot until you subtract the week spent arguing about the logo, the four days lost to a payment gateway that needs a business verification you haven't started, and the fortnight where nobody could decide whether the product was for solo freelancers or 50-person agencies. We've watched all three happen. None of them were engineering problems.
So this is not a guide about writing code faster. It's about what you decide before and during those eight weeks so that the code you write is the code you actually needed. We use roughly this process on SaaS MVPs, and it works because it front-loads the decisions that are expensive to reverse.
First: be honest about whether you need an MVP at all
Sometimes the right answer is not to build. If you haven't spoken to ten people who have the problem you think you're solving, eight weeks of engineering is an expensive way to learn something a fortnight of conversations would have told you for free.
A few situations where we'd tell you to hold off, or spend less:
- Your workflow already runs fine on spreadsheets and nobody is complaining. Automate the painful step, not the whole process.
- You're validating demand, not usability. A landing page, a demo video, and a waitlist will tell you more, cheaper.
- An off-the-shelf tool covers 80% of it. Buying it and living with the gaps for six months is a legitimate strategy — and it teaches you exactly what the missing 20% is worth.
- You have one enterprise buyer who wants a bespoke internal tool. That's a custom build with a different shape, not a SaaS MVP.
If you're past those and you have a specific user with a specific painful workflow, the eight weeks are worth it.
Week 0: the scoping week nobody budgets for
Before the clock starts, we spend a few days getting three things on paper. Not a 40-page spec — three things.
The first is a single primary user. Not a segment, a person with a job title and a Tuesday morning. "Operations manager at a 20-person logistics firm who currently reconciles delivery records by hand" is a user. "SMBs" is not.
The second is the one workflow that must work end to end. In an MVP, one workflow completed properly beats six half-built ones. If your product is a lead tool, the workflow might be: capture lead, assign to a rep, log an activity, see it on a pipeline board. That's it. Reporting, email sequences, and integrations can wait.
The third is your definition of failure. What result, eight weeks after launch, would make you stop? Write it down while you're still calm. It's the only thing that keeps an MVP honest.
Weeks 1–2: architecture decisions and clickable flows, in parallel
Design and architecture happen at the same time, because each constrains the other. While one track sketches screens, the other is answering questions that are painful to change later.
The decisions worth making now
- Tenancy model. Shared database with a tenant column is faster to build and fine for most B2B SaaS. Database-per-tenant is a real cost you should only take on if a customer's compliance posture demands it.
- Authentication. Use a managed provider or a well-maintained framework module. Hand-rolled auth is the single most common place we see MVPs pick up security debt.
- Billing. If you plan to charge in month one, wire up a hosted checkout early — Stripe or equivalent — and start the account verification paperwork in week 1, not week 7.
- Data model for the core entity. Get the shape of your central object right. Everything else can be refactored cheaply; that one can't.
- Hosting and deployment. One environment, one pipeline, automated from day one. Manual deploys will cost you a day a week by week 6.
What design should produce
A clickable prototype of the one workflow, on a component library rather than bespoke pixels. Use something mature — Tailwind with a headless component set, or a design system your team already knows. Custom illustration and a bespoke design language are month-six work. Nobody churned because your empty state was generic.
At the end of week 2 you should be able to click through the whole primary workflow and show it to a real potential user. Do that. Their confusion is cheaper to fix in Figma than in React.
Weeks 3–6: build the spine, then the branches
This is the bulk of the engineering, and the sequencing matters more than the speed. We build vertically: one complete slice of the workflow — database through API through UI — before starting the next. A half-finished feature that works end to end teaches you something. Three finished backends with no interface teach you nothing.
A typical sequence:
- Auth, tenant creation, and user invitation. Boring, unavoidable, and blocks everything else.
- The core entity: create, read, update, list, with permissions.
- The primary workflow's happy path, all the way to the screen a user sees.
- Whatever makes the data useful — a board, a filtered list, a simple export.
- Notifications or emails, if the workflow genuinely depends on them.
- Billing and plan gating, last, because pricing usually changes during the build.
Run a short demo at the end of every week with whoever owns the product decision. Not a status update — a working demo on a real URL. Weekly demos surface scope drift while it's still a conversation instead of a crisis. And keep a visible "not now" list. Every good idea that arrives mid-build goes on it, and stays there. That list is how you protect eight weeks.
If your MVP includes anything genuinely intelligent — document extraction, classification, forecasting — treat it as its own risk item and prototype it in week 1 on real sample data. Model behaviour on your data is the thing most likely to invalidate your plan, and it's the reason we scope AI and ML features separately from the CRUD around them.
Week 7: hardening, not new features
Week 7 is where teams lose MVPs. Someone says "while we're here" and adds a feature, and the launch slips a month. Hold the line. This week is for the unglamorous work that decides whether early users stay.
- Error states and empty states on every screen a new user will hit first.
- Onboarding: how does someone who signed up 30 seconds ago get to their first useful moment? Seeded sample data helps more than a product tour.
- Access control review — check that tenant A genuinely cannot see tenant B's records, at the query level.
- Basic observability: error tracking, uptime checks, and enough logging to debug a customer report without guessing.
- Performance under realistic data volume. Load a few thousand records and click around. N+1 queries surface immediately.
- Backups, and one tested restore. Untested backups are decoration.
Also this week: a short internal runbook. Who gets paged, how to reset a password manually, how to roll back a deploy. Two pages is plenty.
Week 8: launch small, then watch
Launch to a handful of design partners, not the internet. Five to fifteen engaged users will find more real problems in a week than a public launch and a thousand curious signups.
Instrument three things before you open the door: signup completion, first completion of the primary workflow, and return visits within seven days. Vanity metrics can wait. Then sit on calls and watch people use it without helping them. The place where they hesitate is your next sprint.
Expect the first two weeks post-launch to be reactive. Budget for it. An MVP that ships with no capacity to respond to feedback isn't an MVP; it's a launch event.
What eight weeks actually costs — and what it doesn't buy
An eight-week SaaS MVP typically needs a small, senior team: one or two full-stack engineers, part-time design, and someone owning product decisions with real authority. That last role is the one most often left vacant, and it's the most expensive gap. If nobody can say no on the spot, the schedule is fiction.
Be clear about what you won't have at week 8. No SOC 2. No mobile apps. Limited integrations. Rough admin tooling. Documentation that's a Notion page. All of that is normal and appropriate — you're buying evidence, not a finished platform. Retrofitting compliance later is genuinely painful, so if you already know you're selling into healthcare or finance, say so in week 0 and we'll shape the architecture accordingly rather than pretending the constraint doesn't exist.
We've built this way for our own products too — Orbis Lead CRM started as a narrow tool for one workflow before it grew. And for teams who need continuity past launch, an embedded dedicated team tends to work better than a fixed-scope handover, because the two months after launch are where the product actually takes shape.
If you have an idea and a real user in mind, we're happy to spend an hour pressure-testing the scope with you before anyone quotes anything — sometimes that conversation shrinks the build considerably. Take a look at what we've shipped, then get in touch and tell us about the workflow you're trying to fix.
