Start a project without losing the first week: Next.js, Supabase, GitHub and Vercel

01Hesitation costs more than code

At the start of a project, it’s tempting to pick everything with care: the framework, the database, the hosting, how accounts work. You compare, read reviews, and write an API and a login system before you have shown a single screen to anyone. A week goes by and the project still isn’t online.

My view: make these choices once, then reuse them on every new project. I use the same stack wherever I can:

All four have a free tier big enough to launch a project, and none of them makes you rewrite everything the day users show up.

02This site is built this way

ossama.ma runs on this stack. The first commit is from 6 October 2026 at 22:50: Next.js, the three languages (English, French, Arabic), the Supabase schema and seed data. Fifteen minutes later the README had its GitHub + Vercel deployment section. At 08:39 the next morning, the public site followed.

Since then the database has grown to 14 migrations, and a backoffice with two-factor authentication runs on its own subdomain, admin.ossama.ma. I didn’t have to write a separate API server.

03The backend: Supabase

Supabase is a PostgreSQL database wrapped in what a backend usually does: sign-up and login (email, Google, GitHub…), file storage, and a REST API generated from your tables. Create a projects table and the frontend reads it in a few lines:

const { data, error } = await supabase
  .from("projects")
  .select("id, title, published_at")
  .eq("status", "published");

The thing to understand on day one is security. The frontend uses a public key that anyone can see in the browser. Your data is protected by Row Level Security (RLS) rules, written in SQL on each table: who can read which rows, who can write.

alter table projects enable row level security;
 
create policy "public read of published projects"
  on projects for select
  using (status = 'published');

Keep the schema in SQL migration files in the repo instead of clicking around the dashboard. The database is then versioned like the code, and you can recreate it exactly on a second project: a test environment, a client, another region.

04The frontend: Next.js

Next.js handles pages, routing and server rendering, which gives fast pages that Google indexes well. It also brings a small server side with Server Actions and Route Handlers. That is where logic goes that must not run in the browser, such as a call with the Supabase secret key or sending an email.

One repo and one language, TypeScript, cover the interface and the little server code a project needs at the start. The supabase gen types typescript command generates types for your tables, so the editor flags a misspelled column before you even run the site.

05Versioning and publishing: GitHub and Vercel

GitHub keeps the history. Vercel connects to the repo and publishes on every push, with no server to set up. My workflow fits in two branches:

• develop: every push gets a Vercel preview URL. I check the result on a real link, phone included.
• main: production. Changes arrive through a pull request from develop, and the merge puts them live. If a release breaks something, Vercel lets you roll back to the previous deployment while you fix it.

06The first evening, command by command

# 1. The frontend (create-next-app also creates the Git repo and a first commit)
npx create-next-app@latest my-project
cd my-project
 
# 2. The Supabase client
npm install @supabase/supabase-js @supabase/ssr
 
# 3. A versioned schema
npx supabase init
npx supabase migration new init
 
# 4. The GitHub repo
git add . && git commit -m "Supabase setup"
gh repo create my-project --private --source=. --push

Then:

1. Create a project on Supabase and copy its URL and public key.
2. Write your tables in the migration file, then apply it with npx supabase link and npx supabase db push.
3. On Vercel, import the GitHub repo.
4. Add the NEXT_PUBLIC_SUPABASE_URL and NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY environment variables, then deploy. The site is online with HTTPS, a database and auth ready to wire up. The rest of your time goes to the first feature.

07What free gets you, and where it stops

Figures taken in October 2026 from the official Supabase and Vercel pages:

08Growing without a rewrite

When the project takes off, the stack stays the same and only the plans change: Supabase Pro and then a bigger compute instance, Vercel Pro, a custom domain. The code stays where it is. The same Supabase database can also serve a React Native mobile app through the same supabase-js client.

Lock-in is smaller than it looks. Supabase is standard PostgreSQL: one pg_dump exports the whole database to any other Postgres host. Next.js also runs on your own Node.js server or in a Docker container if Vercel stops fitting. The GitHub repo stays yours whatever happens.

The stack does have one clear limit. A Vercel function stops after 300 seconds on the free plan, so long jobs (importing large files, generating reports, a task queue) will need a separate worker. For an MVP, a website, an internal tool or an app with a few thousand users, that limit comes late.