# Why we build everything on Next.js and the edge

> Runtime latency is a conversion killer. Here's our default stack and the reasoning behind every architectural decision.

Source: https://areza.digital/blog/building-with-nextjs-edge
Published: 2026-01-12
Category: Performance

---


We've tried a lot of stacks. After building over 40 production sites and apps, we've converged on Next.js deployed to the edge as our default. Here's the reasoning, including the trade-offs.

## Why Next.js

Next.js gives you the ability to choose the right rendering strategy per route — static generation, server rendering, or client rendering — without switching frameworks.

For a marketing site, most pages are static. The blog is statically generated. The contact form endpoint is server-rendered. The interactive demo is client-rendered. One framework handles all of it.

The App Router (introduced in v13, mature since v15) brings React Server Components, which means you can fetch data on the server and ship zero JavaScript to the client for components that don't need interactivity. A content-heavy page that previously shipped 200KB of JS now ships 15KB.

## Why the edge

Traditional servers run in one region. A user in Singapore hitting a server in us-east-1 is adding 200–300ms of network latency to every request before the server has processed anything.

Edge runtimes — Vercel Edge Functions, Cloudflare Workers — run your code in 30+ locations globally. The server is always close to the user. TTFB consistently under 50ms worldwide.

The trade-off: edge runtimes are constrained. No filesystem access, limited Node.js APIs, smaller memory limits. This forces architectural discipline — stateless functions, data fetched from APIs or edge-cached databases.

## The full stack

- **Framework**: Next.js (App Router)
- **Styling**: Tailwind CSS v4
- **Database**: Postgres on Neon (serverless, edge-compatible) or Supabase
- **Auth**: Clerk or next-auth depending on complexity
- **Email**: Resend
- **Payments**: Stripe
- **CMS**: MDX files in the repo for content-heavy sites; Sanity for client-editable content
- **Deployment**: Vercel

## What we don't use

We don't use client-side rendering for pages that don't require it. We don't use REST APIs where a server action or RSC data fetch is simpler. We don't add a backend framework when Next.js route handlers are sufficient.

Complexity compounds. Every additional service is another thing that can fail, another authentication layer, another deployment pipeline. The right stack is the simplest one that handles the requirements.

Build for the requirements you have. Add complexity only when you've outgrown the simpler solution.


---

## Related

- [Blog](https://areza.digital/blog)
- [Contact](https://areza.digital/contact)