Why We Chose Next.js + Supabase as Our Primary Stack

The Three Questions We Actually Ask

Before any contract is signed, we put every candidate stack through three filters:

1. Delivery: can we ship an MVP in four to eight weeks?
2. Maintainability: can the client's internal team, or a different studio, take over?
3. Total cost of ownership: over twelve months, what do infra, SaaS, and labor combined add up to?

A single red light kills the candidate. Next.js + Supabase is one of the few combinations that clears all three.

Next.js: The Front-End Combo Punch

We value Next.js for four reasons.

• App Router + React Server Components. Most of our marketing pages render on the server, fetch Supabase directly, and send a tiny JS bundle to the client. LCP under 2.5 seconds becomes the default, not an optimization project.
• SEO-first by design. Metadata, Open Graph, hreflang, and JSON-LD are produced server-side. generateMetadata and sitemap.ts let us manage bilingual metadata per case and per blog post in one place.
• Performance plumbing included. next/image, next/font, Route Handlers, and Edge runtime are first-class. Zeabur plus git push replaces a hand-rolled CI pipeline.
• One framework, full stack. Pages, APIs, admin UI, and middleware auth guards all live in one repo under one type system. A single senior engineer can own the whole delivery.

Supabase: A Free Head Start

Supabase compresses one to two weeks of plumbing into a dashboard:

• Auth with email, OAuth, and magic links. @supabase/ssr + a Next.js middleware is enough to lock down /admin.
• Row Level Security moves authorization into the database. Anonymous readers see only published rows; authenticated admins get full access. Our API handlers no longer need to repeat permission checks.
• Realtime (Postgres changes, broadcast, presence) is one flag away, so client dashboards and chat features do not require a separate WebSocket server.
• PostgREST gives every table a REST endpoint out of the box; complex logic drops into an RPC function.

The net effect: we skip a full sprint of "auth + API scaffold + RBAC + DB ops" at the start of every project.

Cloudflare R2 Fills the Storage Gap

Supabase ships its own storage, but for projects with heavy media and public traffic we prefer Cloudflare R2:

• Zero egress fees. For image-heavy portfolios and blogs, R2 is an order of magnitude cheaper than S3 or GCS over twelve months.
• S3-compatible API. @aws-sdk/client-s3 works unchanged.
• Built-in CDN. Buckets bind to custom domains and ride the Cloudflare edge.

Our convention: Supabase owns auth and structured data; R2 owns every blob. Uploads use presigned PUT URLs, so the Node runtime never touches the bytes.

Lessons from Shipping on Next.js 16

Choosing a stack is not about reading docs, it is about surviving upgrade day. Two bruises from this project:

• Next.js 16 breaking changes. Several route-handler signatures now deliver params and searchParams as Promises; stale Next 14/15 snippets blow up at build time. next/dynamic tightened up its server-component contract, and some deprecations turned into hard errors. We now require every agent and engineer on this codebase to consult node_modules/next/dist/docs/ before writing route code.
• Turbopack on NTFS. On Windows NTFS the Turbopack dev server sometimes double-compiles chunks and serves intermittent 404s. The fix is to move the project onto WSL2 / ext4, or fall back to the webpack dev server. The official docs cover this in one sentence; we lost a day rediscovering it.

Net net, we still cut roughly 35% off the delivery timeline versus our previous stack, driven by RLS skipping a permission layer, Server Components making SEO pages "just work", and R2 + presigned URLs keeping media out of our Node process.

What's Next

We are rolling this combo into our client e-commerce, SaaS, and content platform work, and will keep logging the war stories here. If you are weighing Next.js + Supabase for your own project or stuck on an upgrade, reach out via our contact page — we are happy to trade notes.