Why Next.js Is Our Default Stack (And When We Don’t Choose It)

If you look at the Pair Programming portfolio, there’s a clear pattern: nearly every project shares the same stack. Next.js as the framework, React for the UI layer, Supabase for the database and backend, Tailwind and shadcn/ui for styling. It’s not laziness or coincidence. It’s a deliberate architectural decision. Let’s break down the why.

The Criteria: What We Value in a Stack

Before defending the stack itself, here are the principles we use to evaluate it:

1. Time to market: How quickly we can ship a working product.
2. Maintainability: Can a developer who joins 18 months later understand and modify it?
3. Operational cost: No steep monthly floor that eats into runway.
4. Perceived performance: Users should feel the product is fast.
5. SEO-friendly: Critical for public-facing products.
6. Ecosystem maturity: When a problem arises, it’s already solved somewhere.

Why Next.js

Next.js checks all six boxes better than any other framework today:

Hybrid rendering. Next.js lets each page choose between server-side rendering (SSR), static generation at build time (SSG), or full client-side rendering (CSR). This flexibility is huge: your homepage and landing pages go static (blazing fast, SEO-perfect), your internal dashboard uses SSR with auth, and highly interactive components run on the client. One codebase, multiple rendering strategies.

App Router with Server Components. Since Next.js 13+ with the App Router, components render on the server by default. That means less JavaScript shipped to the client, better performance, and the ability to fetch data directly in the component—no separate API layer required.

Built-in optimization for images, fonts, and scripts. next/image handles lazy loading, srcset, and modern formats automatically. next/font eliminates layout shift from font loading. next/script manages execution order. What would take weeks to configure in another stack comes out of the box in Next.js.

First-class SEO support. The framework’s structure is designed for indexable sites: per-page metadata APIs, dynamic sitemaps, robots.txt, rewrites and redirects in config, and easy structured data. We’ve built programmatic SEO with hundreds of indexable pages without fighting the framework.

Deploy to Vercel. Zero configuration, global edge network, automatic scaling, and pull request previews. Cost starts at $0 and scales only when real traffic kicks in.

Why Supabase Fits Perfectly

React alone isn’t enough—you need data, auth, and storage. Your options are: build everything from scratch (slow), start with AWS (complex), or use a backend-as-a-service (BaaS). Among BaaS options, Supabase stands out because:

• Real Postgres, not a pseudo-database like Firebase. Full SQL, relationships, transactions—everything you’d expect.
• Complete auth built in, with magic links, OAuth, and social logins.
• Row-level security (RLS) at the database level, critical for multi-tenant apps.
• Storage with CDN for file uploads.
• Open source, so you can self-host if the project ever scales beyond the cloud.
• pgvector for embeddings and AI (we use it in Tontin).
• Edge functions for custom server-side logic.

The Stack in Action: Four Very Different Projects

The beauty of this stack is that it adapts to wildly different contexts without friction:

Mi Seguro de Auto: Public-facing product with high SEO traffic and deep integrations with insurance carriers. Next.js serves programmatic pages optimized for Google, Supabase stores quotes and leads. Every page is lightweight and loads fast on mobile—the platform where 80% of users get quotes.

La Carolina: Internal CRM that doesn’t need SEO but requires robust auth, multi-tenancy, and performance for complex operations. Same stack, different approach: server components for data fetching, RLS for isolation, bidirectional sync with Google Calendar via edge functions.

Tontin: Heavy AI platform featuring embeddings and multiple LLM fallback chains. Next.js orchestrates the frontend and API layer, Supabase stores conversations and embeddings using pgvector, and edge functions handle model calls.

Zweifel Capital: Premium family-office site serving London, Buenos Aires, and Nassau. Entirely static, meticulously designed, multi-language. Next.js + Tailwind, static deploy on Vercel. Zero database, zero backend—all edge. Another face of the same stack.

When We Don’t Choose Next.js

There are scenarios where another stack makes more sense:

• Heavy backend without UI: If your goal is a pure API with no frontend, Fastify or NestJS are better fits.
• Native mobile apps: React Native is a different beast. For true native performance, go with Flutter or native Swift/Kotlin.
• Complex realtime apps: For collaborative editors like Figma or multiplayer games, you need heavier client-side stacks like Vue + Pinia + WebRTC or similar.
• Ultra-simple sites: A single-product landing page might be better off in Astro or even plain HTML/CSS. Next.js is overkill here.

The Strongest Argument: Boring Consistency

The best thing about sticking to a consistent stack is positive boredom. We’re not re-evaluating tools, debating alternatives, or reinventing patterns for every project. The team knows the tools inside out, common problems are already solved, and we can focus energy on solving the client’s actual problem—that’s what matters.

Bottom Line

Next.js + React + Supabase + Tailwind covers almost the entire modern web application spectrum. It’s not the best tool for every job, but it’s good enough for nearly everything common and outstanding for the most frequent use cases. That combination of versatility and maturity makes it the sensible default today.

If you’re deciding on a stack for a new project or evaluating a migration, let’s talk. We’ll help you think through the technical decision based on your product, team, and timeline.

---

By Esteban Aleart, Founder & Lead Engineer at Pair Programming.