How to vibe code a SaaS with Supabase and Vercel in a weekend

If you want to vibe code a SaaS, getting a working version online in a weekend is realistic now. The hard part isn't writing the code: your agent will write plenty. It's ending Sunday with something that's secure, deployed and still understandable on Monday.

This is the two-day plan we'd follow with an AI coding agent (Cursor, Claude Code, Codex or similar), Next.js, Supabase for the database and auth, and Vercel for hosting. The example is a simple "client portal" where users sign in and manage their own records, but the steps fit most CRUD-style SaaS ideas.

Before you vibe code a SaaS: decide what you're not building

Write one paragraph: who it's for, the single job it does, and the 3–5 screens it needs. Then make a "not in v1" list (teams, roles, billing tiers, admin dashboards, mobile app). Paste both into your agent and ask for a plan before it writes any code. Our prompt starter pack has a template for this.

Saturday morning: project scaffolding

1. Create a Supabase project from the Supabase Dashboard (Supabase Next.js quickstart).

2. Scaffold the app with the official template. It comes with cookie-based auth, TypeScript and Tailwind CSS already set up:

npx create-next-app@latest my-app -e with-supabase

The template installs @supabase/supabase-js and @supabase/ssr, and creates a browser client in lib/supabase/client.ts and a server client in lib/supabase/server.ts (quickstart).

3. Add your environment variables. Rename .env.example to .env.local and fill in the two values from your project's Connect panel:

NEXT_PUBLIC_SUPABASE_URL=https://your-project.supabase.co
NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY=sb_publishable_...

The publishable key is designed to be public. It only reaches what your Row Level Security policies allow. Supabase is deprecating the older anon and service_role keys by the end of 2026, so if a tutorial (or your AI) tells you to paste a long key that starts with eyJ, it was written for the legacy keys (Supabase API keys).

4. Give your agent context (optional, but worth it). Supabase publishes agent skills (npx skills add supabase/agent-skills) and a hosted MCP server, so your agent works from current Supabase patterns instead of whatever it remembers from training (quickstart). If you connect the MCP server, scope it to this one project, and use read_only=true while you're exploring (Supabase MCP).

Saturday afternoon: Supabase data model and Row Level Security

This is the step most weekend builds get wrong, so do it before any UI.

Ask your agent for a migration, and make it follow Supabase's RLS procedure: enable RLS, revoke the default grants, grant back only what each role needs, and write one policy per operation. For a table where each user owns their rows, it looks like this:

create table public.projects (
  id uuid primary key default gen_random_uuid(),
  user_id uuid not null references auth.users (id),
  name text not null,
  created_at timestamptz not null default now()
);

alter table public.projects enable row level security;

revoke all on table public.projects from anon, authenticated;
grant select, insert, update, delete on table public.projects to authenticated;

create policy "owners read projects" on public.projects
  for select to authenticated using ((select auth.uid()) = user_id);

create policy "owners create projects" on public.projects
  for insert to authenticated with check ((select auth.uid()) = user_id);

create policy "owners update projects" on public.projects
  for update to authenticated
  using ((select auth.uid()) = user_id)
  with check ((select auth.uid()) = user_id);

create policy "owners delete projects" on public.projects
  for delete to authenticated using ((select auth.uid()) = user_id);

create index projects_user_id_idx on public.projects using btree (user_id);

Why each piece is there, according to Supabase's docs:

• A table in an exposed schema without RLS is readable and writable by any role with a grant on it. Policies alone don't take existing grants back.
• with check on update stops a user from reassigning a row to someone else.
• Wrapping auth.uid() in select lets Postgres cache the result per statement instead of calling it for every row.
• Indexing user_id keeps the policy fast as the table grows.

Then test it. Supabase recommends a pgTAP test file per table under supabase/tests/, run with supabase test db, that checks both what's allowed and what's denied for anon and authenticated. In their words: "Until the suite passes, you don't know whether the policies do what you intended." Ask your agent to write these tests from the policies, and include a "user B can't see user A's rows" case. Our Supabase RLS audit skill packages these checks for your agent.

Saturday evening: auth and the first feature

The template already has sign-up and sign-in. Your job is to:

1. Decide which routes are public. The template redirects signed-out visitors to the sign-in page for most routes, and the quickstart shows how to add exceptions in lib/supabase/proxy.ts (quickstart).
2. Build one feature as a vertical slice: list, create, edit and delete for your main table, using the server client.
3. Run the build and tests before you stop for the night.

Sunday morning: deploy to Vercel

1. Push to GitHub and import the repo into Vercel. The first deployment of a new project is always a production deployment. After that, pushes to main deploy to production, and other branches and pull requests get preview deployments with their own URLs (Vercel environments).

2. Connect Supabase. The Supabase integration on the Vercel Marketplace can sync your Supabase environment variables to your Vercel project automatically, including NEXT_PUBLIC_SUPABASE_URL and NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY. It also adds server-side variables such as SUPABASE_SECRET_KEY and Postgres connection strings, so treat the whole set with care. You can also add variables by hand in project settings. Either way, remember that environment variable changes apply to new deployments only (Vercel env vars).

3. Mind the NEXT_PUBLIC_ rule. Next.js inlines any NEXT_PUBLIC_ variable into the JavaScript sent to the browser at build time (Next.js docs). The publishable key belongs there. The secret key, which bypasses RLS, must never get that prefix (Supabase API keys).

4. Set auth redirect URLs in Supabase for your production domain, so sign-up confirmation emails point to the live site. Ask your agent to list every URL the auth flow uses.

Sunday afternoon: billing (optional) and polish

If you're charging from day one, Stripe Checkout gives you a prebuilt payment page for one-time and subscription payments, so you don't have to build card forms yourself. Keep the Stripe secret key server-side, just like the Supabase one.

Then polish what matters: empty states, error messages, a 404 page and a landing page that says what the product does in one sentence.

Sunday evening: the launch checklist

Before you share the link, go through this list:

• [ ] Every table has RLS enabled, and the pgTAP tests pass.
• [ ] No secret has a NEXT_PUBLIC_ prefix, and none is committed to Git.
• [ ] Production and Preview have the environment variables they need.
• [ ] Auth redirect URLs match the production domain.
• [ ] The build passes on Vercel, and you've clicked through the main flow on the live URL.
• [ ] You've read the full diff at least once. See our checklist for reviewing AI-generated code.

Supabase's own production notes say the same thing: review your RLS policies, keep credentials in environment variables rather than source control, and set up a custom domain when you go live.

What the weekend version won't cover

A weekend build is a v1. Roles and teams, audit logs, backups you've actually tested, rate limiting and proper monitoring come next. Plan for them before real customers depend on the product.

Keep reading

• Git and GitHub basics for vibe coders
• How to back up and export your Supabase database
• Pre-deploy check skill for coding agents

FAQ

Can you really build a SaaS in a weekend with AI?

You can ship a small, secure v1 in a weekend if you keep the scope tight. Roles, audit logs, tested backups, rate limiting and monitoring usually come after.

Which Supabase key is safe to use in the browser?

Only the publishable key. It reaches only what your Row Level Security policies allow. The secret key bypasses RLS and must never get a NEXT_PUBLIC_ prefix.

How do I test Supabase Row Level Security?

Supabase recommends a pgTAP test file per table under supabase/tests/, run with supabase test db, that checks what anon and authenticated users can and cannot do.

Does Vercel deploy every branch?

After the first deployment, pushes to main deploy to production, and other branches and pull requests get preview deployments with their own URLs.