Dynamic

Site with login, forms, or a CMS

Last reviewed:

GitHubCursorSupabase or SanityVercel

Get started

How to get started

Baseline

Time: Half a day to a day for a working auth or CMS baseline

Accounts before step 1: GitHub, Cursor, Supabase or Sanity, Vercel

  1. Start a project in GitHub

    Create a repo and scaffold Next.js or Astro locally — or generate a starter in Cursor and commit it.

  2. Add Supabase or Sanity

    Use Supabase when you need auth, forms, or a database. Use Sanity when the job is editorial — writers need a structured CMS, not wp-admin.

  3. Drive changes from your editor

    Use Cursor or OpenAI Codex to wire pages to your data layer. Keep schema and queries in the repo so you can migrate later.

  4. Deploy from the repo

    Connect GitHub to Vercel (or Cloudflare Pages if the stack fits). Environment variables for Supabase or Sanity live in the host dashboard.

Ownership

What you keep

You keep: Git repository plus database or CMS you can export or self-host

Cost shape: Free tiers available on agents, databases, and hosts; paid tiers as usage grows.

Named tools

Tools this path uses

  • GitHub
  • Cursor
  • Next.js
  • Astro
  • Supabase
  • Sanity
  • Vercel

Quick answers

Frequently asked questions

When should I not start here?
If the site is a brochure or landing page with no login, forms, or editorial CMS, use the Brochure path instead. Adding Supabase or Sanity early is overhead you do not need.
Supabase or Sanity?
Supabase for auth, member areas, and app data. Sanity for editorial teams who need structured content and previews. Both export or self-host — check current docs before you commit.
Do I still own the project?
Yes. The repo is yours. The database or CMS is a service you can export from or self-host — unlike a hosted canvas where editing stays in the vendor app.