Shipping a SaaS MVP in 4 Weeks With Next.js and Supabase: My Actual Process | Ryan Katayi

Most MVP timelines are not ruined by code.

They are ruined by pretending the first version is secretly version three.

The founder says "MVP," but the feature list says enterprise dashboard, billing, teams, notifications, admin permissions, AI assistant, exports, onboarding, analytics, and "just one more thing" that turns out to be its own product.

I have been there. I have shipped a lot of small-to-medium products for founders and teams, and the pattern is familiar now: the business idea is usually sharper than the build plan.

That is not a criticism. Founders are supposed to see the whole thing. My job is to help turn that into a first version that can actually be built, used, and learned from.

For that kind of work, I reach for Next.js and Supabase a lot.

Not because they are trendy. Not because every app should use them. Because together they let me get the boring-but-critical parts of a SaaS app working quickly: auth, database, protected pages, file storage, server-side data access, simple APIs, and deployment.

The stack does not solve scope. Nothing solves scope except making decisions.

But the right stack gives you fewer excuses.

Here is how I usually ship a focused SaaS MVP in about four weeks.

Before week one: cut the product in half

The real work starts before I write code.

I want to know one thing:

What does a user need to do for this product to be worth testing?

Not worth dreaming about. Not worth raising money on. Worth testing.

For an MVP, I like a brutal filter:

Does this help the user reach the main outcome?
Does this help the founder learn whether the product should exist?
Does this reduce risk before money or user trust is involved?

If the answer is no, it probably does not belong in the first build.

This is where a lot of projects get uncomfortable. Dashboards feel productive. Settings pages feel serious. Admin panels feel safe. But the product usually lives in one core workflow.

For L'Atelier, the product was not "a language learning platform" in the abstract. It was real conversation practice that helped newcomers to Canada build confidence in French.

For Axlow, the product was not "AI for healthcare." It was asking a policy question and getting a sourced answer without digging through documents for hours.

For Fluenta, the product was not "a language app." It was live speaking practice that felt more natural than drills.

That is the level I want before week one. One sentence that makes the product smaller and stronger.

Week 1: auth, schema, and the boring foundation

The first week is not glamorous.

That is the point.

I want the product skeleton in place early:

Next.js app structure
Supabase project
environment variables
auth flow
database schema
Row Level Security
protected routes
basic dashboard shell
deployment pipeline

I do not like waiting until the end to deploy. If the app only exists on my laptop for three weeks, the project is lying to me. I want production or preview deployments early so auth redirects, environment variables, cookies, and server-side data access fail loudly while the app is still small.

For Supabase auth with Next.js, I usually follow the current @supabase/ssr direction: separate clients for browser and server usage, cookie-based sessions, and server-side helpers where the app needs them.

The important decision is not the exact helper file names. It is drawing a line between:

server-side data that should never leak into the client bundle
client-side interactions that need the browser
database policies that protect the data either way

Next.js Server Components are useful here because I can fetch data on the server and avoid shipping database query logic to the browser. But that does not remove the need for authorization. Server-side code still needs to know who the user is and what they are allowed to access.

For a basic SaaS shape, I usually start with:

create table public.organizations (
  id uuid primary key default gen_random_uuid(),
  name text not null,
  created_at timestamptz not null default now()
);

create table public.memberships (
  organization_id uuid not null references public.organizations(id) on delete cascade,
  user_id uuid not null references auth.users(id) on delete cascade,
  role text not null check (role in ('owner', 'admin', 'member')),
  created_at timestamptz not null default now(),
  primary key (organization_id, user_id)
);

Even if the first version only has one user per account, I still think about the team model early. Retrofitting organizations after launch is painful. You do not need a full enterprise permissions system on day one, but you should avoid designing yourself into a corner.

And yes, RLS is enabled immediately.

Week one ends when a user can sign in, land in the app, and access only the data they should access.

That is not the product yet. It is the floor.

Week 2: build the one thing

Week two is where the actual product starts to appear.

This is also where scope tries to escape.

I try to spend week two on the core workflow only. The one thing. The thing that would make a user say, "Okay, I understand why this exists."

For an AI document search product, that might be:

Upload or ingest documents.
Ask a question.
Retrieve relevant sources.
Generate an answer with citations.
Let the user inspect the source.

For an internal dashboard, it might be:

Import records.
Review status.
Assign work.
Mark an item complete.
See what changed.

For a marketplace, it might be:

Create a listing.
Browse listings.
Contact or transact.
Track the request.

Everything else is support.

This is where Next.js and Supabase feel fast. Server Components can fetch initial data. Client Components handle interactive pieces. Supabase gives me Postgres, Auth, Storage, and real-time subscriptions when the product actually needs live updates.

The key phrase is "when the product actually needs it."

Real-time is great when multiple people are looking at the same operational state. It is noise when a normal refresh or refetch is enough.

Same with AI. Same with charts. Same with notifications.

The MVP should feel useful, not decorated.

Week 3: billing, onboarding, and the states people forget

Week three is where a demo starts becoming a product.

This is when I add the things users notice when they are no longer being guided through the app on a call:

onboarding
empty states
loading states
error states
permission states
billing or plan gating
basic emails
admin visibility

The unglamorous states matter.

A blank dashboard with no explanation feels broken. A spinner with no context feels fragile. A form error that says "Something went wrong" makes users stop trusting the app. A disabled button with no reason creates support messages.

This is also when billing usually lands if the MVP needs it.

Stripe subscriptions are asynchronous. That means webhooks are not optional decoration. Stripe's own docs recommend using webhooks for subscription lifecycle events because important changes do not always happen during the user's current browser session.

So I avoid treating checkout success as the source of truth.

A typical billing flow looks like:

User starts checkout.
Stripe handles payment.
Webhook receives subscription event.
Server verifies the webhook signature.
Database updates subscription status.
App gates features based on the database, not wishful thinking.

I want the app to survive the boring edge cases:

payment fails
card changes
trial ends
subscription cancels
webhook retries
user closes the tab after checkout

An MVP does not need a perfect billing portal. It does need to avoid giving paid access based on vibes.

Week 4: deployment, monitoring, and handoff

By week four, I want to stop adding ambition and start removing uncertainty.

This week is for:

production deployment
environment variable checks
smoke testing
mobile layout pass
analytics
error monitoring
security review
handoff docs
founder walkthrough

If the app is on Vercel, environment variables need to be set for the right environments. Changing env vars does not magically update old deployments; you redeploy. That sounds obvious until someone spends an hour debugging a missing key that was added after the deployment they are testing.

I also like to leave behind a short handoff note:

what the app does
where the important routes are
how auth works
where database tables live
which env vars matter
how to deploy
known trade-offs
what I would build next

That last section is important. Every MVP has trade-offs. I would rather name them clearly than pretend the first version is finished forever.

The stack I keep coming back to

My default MVP stack often looks like this:

Next.js for the app
TypeScript because future-me deserves kindness
Supabase for Postgres, Auth, Storage, and RLS
Tailwind for fast, consistent UI
Stripe if money is involved
Vercel for deployment
PostHog, Vercel Analytics, or Google Analytics depending on what needs measuring

This stack works because it keeps the architecture simple.

The database is Postgres. Auth is integrated. RLS protects rows. The app can render on the server. Deployment is boring. There is enough room to grow without spending week one wiring infrastructure nobody will use yet.

But I do not think every MVP should use the same stack.

If the product is mobile-first, React Native or Swift might matter more. If the team already has a backend, I do not rip it out for fun. If the app has complex background jobs, I plan for that early.

Good stack choices are contextual. Bad stack choices are usually emotional.

The parts I do not skip

I will cut features aggressively. I do not like cutting these:

authentication
authorization
database constraints
RLS
input validation
error states
deployment checks
basic analytics
a clear handoff

Those are not "enterprise" features. They are how you avoid building a demo that collapses the first time a real user touches it.

An MVP should be small. It should not be sloppy.

What founders usually underestimate

Founders tend to underestimate three things.

First, decisions take longer than code.

If every screen waits for a product decision, the timeline slips even if the engineering is fast. I can build faster when the product has a clear spine.

Second, edge cases appear earlier than expected.

Users forget passwords. They upload weird files. They use mobile. They paste long text. They click twice. They leave tabs open. They invite the wrong email. They cancel subscriptions.

The MVP does not need to handle every edge case beautifully, but it should not break in the obvious places.

Third, launch is not the finish line.

The point of an MVP is to create feedback. That means the first version should be instrumented enough to learn from. Which pages are used? Where do people drop off? What do they try to do twice? What questions keep coming back?

Without that, you did not ship a learning machine. You shipped a guess.

What I would build first if you came to me with an idea

I would not start with the dashboard.

I would start with the core action.

If the product helps people search documents, we build search first.

If it helps teams manage work, we build the work loop first.

If it helps users practice speaking, we build the conversation first.

Then I build the minimum shell around it:

sign in
create or join workspace
use the core workflow
see history
manage billing if needed
contact support or request changes

That is usually enough for a first version. Not enough for the dream. Enough to learn.

And learning is the whole point.

The hard part is not Next.js or Supabase

Next.js and Supabase are good tools. They help me move fast without pretending security and data modeling do not exist.

But the stack is not the hard part.

The hard part is saying no to features that feel reasonable.

The hard part is shipping something small enough to finish and useful enough to test.

The hard part is remembering that an MVP is not a smaller version of your final product. It is a tool for finding out what the final product should become.

Four weeks is possible when the product has that discipline.

Without it, even four months disappears.