All posts
Technology

Why We Build with Next.js (And When We'd Recommend Something Else)

A plain-English look at why Next.js has become our default framework — performance, SEO, developer experience, deployment — and the cases where it's genuinely not the right call.

Daniel Greener-VigilAugust 10, 20256 min read
Next.js
React
web framework
web development technology
frontend development

Every development shop has opinions about their tech stack. Ours tend to center on Next.js. Not because it's trendy (though it is), but because after building dozens of products on it, we've seen it consistently make the right tradeoffs for most of what our clients need.

Here's an honest breakdown of why we default to it, what it actually gives you, and the cases where we'd recommend something else.

What Next.js Is (Without the Jargon)

React is a JavaScript library for building user interfaces. On its own, React doesn't tell you how to handle routing, data fetching, server-side rendering, or deployment. You have to assemble those pieces yourself — and the choices you make early tend to compound.

Next.js is a framework built on top of React that makes those decisions for you — thoughtfully. It gives you:

  • A file-based routing system (the structure of your files defines your URL structure)
  • Multiple rendering strategies: fully static, server-rendered, client-rendered, or mixed
  • API routes built into the same codebase
  • Built-in image optimization
  • A great developer experience out of the box

The result is a framework that you can go from zero to production with faster than almost anything else, without accumulating architectural debt you'll regret later.

Why It's Usually the Right Choice

Performance by default

The biggest real-world advantage of Next.js is what it does for page performance without you thinking about it.

Static pages are pre-rendered at build time and served from a CDN — effectively instant. Server-rendered pages generate HTML on the server before sending it to the browser, so users see real content immediately instead of a blank screen while JavaScript loads. Images are automatically optimized, lazy-loaded, and served in modern formats.

Google's Core Web Vitals — Largest Contentful Paint, Cumulative Layout Shift, First Input Delay — are all directly influenced by this. A well-built Next.js app tends to score well on these without heroic optimization effort.

SEO out of the box

A standard React app (without Next.js) sends a nearly empty HTML file to the browser and then populates the page with JavaScript. Search crawlers can process this, but they're much better at reading real HTML in the initial response.

Next.js server-renders your pages by default. The crawler gets a fully-formed HTML document with your title tags, meta descriptions, heading structure, and content — all the signals that influence ranking. For marketing sites, content pages, and anything where discoverability matters, this is a meaningful difference.

One codebase for frontend and backend

Next.js API routes mean you can write server-side logic — data fetching, form handling, third-party API calls, authentication — in the same project as your frontend. For most projects this is a massive simplification. Instead of maintaining a separate backend service, a separate deployment, and coordinating between them, it all lives together.

This isn't the right architecture for every project (more on that below), but for the majority of web applications, it's a massive simplification.

The deployment story is excellent

Next.js deploys seamlessly to Vercel (built by the same team) and works very well on AWS, Google Cloud, and other platforms. Infrastructure setup that used to take days can take hours. Preview deployments — where every pull request gets its own live URL to review — are trivially easy. This speeds up feedback loops significantly.

The ecosystem is mature

Next.js has been around since 2016. The ecosystem around it is enormous: libraries, tutorials, third-party integrations, community support. When we run into an edge case or a problem, there's almost always a well-documented solution. For clients who eventually want to hire their own engineers, finding someone who knows Next.js is much easier than finding someone who knows an obscure framework.

What Next.js Is Not Great For

Being honest about tradeoffs is part of choosing tools well.

Highly interactive, real-time applications

Applications where the primary interface is a continuously-updating, complex UI — think collaborative document editors, real-time dashboards, or complex data visualization tools — often perform better with a dedicated client-side approach. Next.js can handle these, but the server-rendering model adds friction in cases where you don't actually benefit from it.

Applications that are mostly API consumers

If your "frontend" is more like a thick client — a dashboard that pulls from multiple APIs and has very little static content — the overhead of Next.js's rendering infrastructure may not be worth it. A lighter React setup or even a different framework might be more appropriate.

Mobile apps

Next.js is a web framework. If you need iOS and Android apps, you need React Native or a native solution. They share the React mental model, which helps with team familiarity, but they're different tools.

Simple static sites with no interactivity

If you need a basic informational site with no dynamic behavior, no user accounts, and no data fetching, something like Astro or even plain HTML/CSS is faster to build and simpler to maintain. Next.js is powerful, but power comes with complexity. Don't use a sports car to drive to the corner store.

How We Actually Use It

For most client projects, our typical setup:

  • Next.js App Router — the current routing model, which colocates components, layouts, loading states, and error handling cleanly
  • TypeScript — always. The type safety catches entire categories of bugs before they reach production
  • Tailwind CSS — utility-first styling that's fast to write and easy to maintain across a team
  • shadcn/ui — a component library that gives us accessible, well-built primitives we can style freely
  • Vercel — for most deployments, though we adapt to whatever infrastructure a client already uses

This stack is not precious to us. We use it because it consistently produces well-performing, maintainable products. If your situation calls for something different, we'll say so.

The Right Framework Is the One That Fits Your Product

We use Next.js because it's the best fit for most of what we build: marketing sites, web applications, content-driven products, SaaS platforms, client portals. It handles SEO, performance, and developer productivity well in a single cohesive package.

If you're evaluating technology for a new project and want a straight answer about what makes sense for your specific situation, reach out. We'd rather give you an honest recommendation than sell you on a stack.

Ready to start your project?

Get a free, no-pressure quote from our team.

Get a Free Quote