The Stack I Use to Ship a SaaS MVP in Weeks, Not Months
Most MVPs are late for the same reason: the team spends the first month on decisions that do not affect whether anyone wants the product.
Auth strategy. Monorepo layout. Which state manager. Whether to use microservices "so it scales later." None of it matters if the thing nobody asked for launches in November instead of September.
My approach is the opposite. I use one boring, opinionated stack for almost every MVP, and I spend the saved time on the part that actually decides the outcome: the product itself.
The stack
Next.js (App Router) for the whole application — marketing pages, dashboard, and API in one deployable unit. Server components mean most pages fetch their own data with no client-side loading states to design, no API layer to maintain, and no over-fetching to debug.
Supabase for Postgres, auth, storage, and row-level security. This is the biggest single time saver. Auth that would take a week is an afternoon, and RLS means authorisation rules live next to the data instead of scattered across route handlers where they rot.
TypeScript everywhere, generated types from the database schema. When a column changes, the compiler tells me what broke instead of a user telling me later.
Tailwind for styling, with design tokens defined once as CSS variables. Theming and dark mode become configuration rather than a refactor.
Vercel for deploys, previews, and analytics. Every pull request gets a live URL the client can click, which changes review from "here is a screenshot" to "here, try it."
Why boring wins
Every novel piece of technology in an MVP is a bet that you will spend time learning it instead of building. Sometimes that bet pays. Usually it does not.
A boring stack means: the error message has been on Stack Overflow since 2023, the AI assistant in my editor has seen it thousands of times, and the client's next developer can pick it up. That last one matters more than people admit. Handing over a codebase nobody else can maintain is not a favour.
Where AI actually earns its place
I use AI heavily while building — and almost never as the product's core value proposition unless the client's problem genuinely needs it.
Where it pays off during development:
- Scaffolding, not architecture. Generating forms, table components, and CRUD handlers is fast and low-risk. Designing the data model is not — that is where a wrong call costs weeks.
- Migration and translation work. Converting a design to markup, or an entire UI to a second language, is exactly the kind of high-volume, low-ambiguity work models are good at.
- The first draft of a test suite. Models are good at enumerating cases you would forget, and the tests either pass or they do not, so the feedback is honest.
Where it does not:
- Anything security-relevant. Auth flows, permission checks, and payment handling get written and reviewed by a human, every time.
- Decisions with no undo. Schema design, third-party lock-in, pricing model. Generated code is confident about these in a way it has not earned.
The sequence that keeps projects on schedule
- Week 1 — the spine. Auth, database schema, deploy pipeline, and one real end-to-end flow. Nothing pretty. The goal is a live URL where you can sign up and do the single most important action.
- Week 2–3 — the core loop. Build only the actions users must repeat for the product to make sense. Resist every "while we're in here" feature.
- Week 4 — the edges. Billing, emails, empty states, error states, mobile. This is where MVPs feel unfinished, and it is almost always underestimated.
- Then — polish against real usage. Not before. Design decisions made without watching someone use the product are guesses.
What I skip on purpose
No admin panel until someone needs one; the database GUI is fine. No custom design system; a component library plus tokens gets you 90% there. No test coverage target; tests go on the money paths and the logic that is genuinely hard to reason about, not on rendering a button.
And no scaling work. A managed Postgres will carry you comfortably past the point where you have proven the product deserves to scale. Optimising for the traffic you hope to have is the most expensive form of procrastination in software.
My definition of done for an MVP
"Done" is the vaguest word in software, so I make it concrete before week one. An MVP ships when all of this is true — and notably, none of these are features:
| Area | The bar |
|---|---|
| Signup | A stranger can create an account and reach the core action without me |
| Core loop | The main action works end to end, on a phone, on a bad connection |
| Money | If it charges, a real card completes and a failed card fails gracefully |
| Empty states | Every list explains what to do when it has nothing in it |
| Errors | Nothing shows a raw stack trace; every failure suggests a next step |
| Signup, password reset, and receipts actually arrive and are not spam | |
| Data | I can answer "how many users did X?" without writing a migration |
| Recovery | Backups exist and I have restored one at least once |
That last row is the one teams skip. An untested backup is a rumour, not a backup.
Anything not on this list is version two. Writing it down at the start is what makes "can we just add…" a conversation about the next release instead of a slip in this one.
The uncomfortable truth
The stack is not what makes an MVP succeed. Shipping it while the idea is still relevant is.
Pick tools you can move fast in, cut the scope harder than feels comfortable, and get it in front of users. You can rebuild anything later with the money the working version earns.