Why We Build With Next.js, And When We Don't

Every agency has a default stack, and ours is Next.js. When a prospective client asks why, we don't give them a sales pitch about React Server Components. We explain the actual tradeoffs, and when the answer to 'should we use Next.js?' is genuinely no.

What Next.js actually buys you

Next.js is opinionated in ways that align with what high performance marketing sites need. Routing, image optimization, font loading, server side rendering, and static generation are all handled by the framework rather than assembled from separate libraries. That means fewer integration decisions, a smaller surface area for performance bugs, and a codebase that's easier to maintain two years from now.

The App Router (introduced in Next.js 13, matured through 15 and 16) enables partial rendering, streaming, and server components that dramatically reduce the JavaScript shipped to the browser. For a marketing site where most content is static, this means near instant page loads and excellent Core Web Vitals without heroic optimization effort.

• Built in Image component handles WebP/AVIF conversion, lazy loading, and aspect ratio locking automatically
• Font optimization eliminates layout shift from web fonts without any manual configuration
• Server components mean heavy components (markdown renderers, icon libraries) don't add to client bundle size
• Incremental Static Regeneration lets content stay fresh without sacrificing performance
• The Vercel deployment pipeline is genuinely the smoothest production DX available

The real argument: ownership and longevity

Beyond performance, the argument for Next.js over page builder tools is ownership. A Webflow or Framer site is hosted on someone else's infrastructure, locked into their pricing, and limited to the features their platform exposes. A Next.js site is code you own, deployable anywhere, extensible without vendor permission.

We've seen clients get burned by platform pricing changes, feature deprecations, and export limitations on hosted builders. We've never seen a client regret owning their codebase.

When we don't use Next.js

Content heavy sites with non technical editors

If a client has a team of content editors who need to manage complex page layouts without developer involvement, a visual CMS like Contentful or Sanity paired with a component library can be the right answer. Next.js integrates with both, but the editorial experience for free form layout control is better in a purpose built tool.

Simple landing pages with no ongoing development

If a client needs a single page campaign landing page and has no intention of maintaining or extending it, Framer or a simple static HTML/CSS build may be more appropriate. The overhead of a full Next.js project isn't justified for something genuinely that contained.

Large ecommerce with complex merchandising logic

For ecommerce at scale, we typically integrate Next.js as the front end layer against a Shopify or Medusa back end rather than building the commerce logic from scratch. Shopify's Hydrogen framework is also worth considering for Shopify native builds. It's React based and handles enough ecommerce complexity that rebuilding those patterns in Next.js adds cost without adding value.

“The right tool is the one that's still right in three years. That's always the question we're actually answering.”

CalDesign Engineering Team

The version question

Next.js 16 shipped significant breaking changes: async cookies/headers, a renamed middleware API, and changes to caching defaults. We stay current on major versions and handle upgrades as part of our maintenance retainers. Clients on older versions aren't unsupported, but they're missing real performance and security improvements, and the longer you wait, the larger the migration delta.