Why we build business web applications with Next.js — and when we don't

Clients sometimes ask why we reach for the same framework so often. The fair answer is that choosing a framework is a business decision as much as a technical one. It affects how quickly features ship, how easy it is to hire people who can maintain the code, how the application performs for users and search engines, and how much of the plumbing you have to build yourself.

For most of the web applications we build, from customer portals and marketing sites to SaaS products and internal tools, Next.js is a strong default. This article explains why, and just as importantly, the situations where we would recommend something else.

One codebase for the interface and the server

Next.js is built on React, which has a very large ecosystem and a deep pool of developers. On top of that it adds routing, server-side code, data fetching and build tooling in one coherent package. With TypeScript throughout, the same types describe your data from the database query to the component that displays it.

For a business, the practical benefit is fewer moving parts. Many applications do not need a separate API service for their own front end; the server logic can live alongside the pages that use it. That means fewer deployments to coordinate, fewer places for bugs to hide, and a smaller surface for a future team to learn. When you do need a public API for partners or mobile apps, you can still build one, but you are not forced into it on day one.

Server components change the defaults

In the App Router, components render on the server by default. They can query a database or call an internal service directly, and send the browser finished HTML rather than a large bundle of JavaScript that has to fetch data after loading. Interactivity is added only where it is needed, by marking specific components as client components.

This matters for business applications because much of what they show is data: tables, records, reports, account details. Rendering those on the server keeps secrets and database credentials off the client, reduces the JavaScript users download, and usually makes pages feel faster, particularly on modest devices and slower connections. Server actions provide a straightforward way to handle form submissions and mutations with validation on the server, where it belongs.

Send the browser finished pages, and add interactivity only where people actually interact.

Choosing a rendering strategy per page

Not every page has the same needs, and Next.js lets you choose per route rather than committing the whole application to one approach:

• Static rendering for content that changes rarely, such as marketing pages, documentation and articles. These are fast, cheap to serve and excellent for search.
• Revalidation for content that changes periodically, such as product listings, where pages are cached and refreshed on a schedule or when data changes.
• Dynamic rendering for anything personal or real-time, such as dashboards, account pages and anything behind a login.
• Streaming to show the fast parts of a page immediately while slower data loads, rather than making users wait for everything.

Caching is powerful but deserves care. It is one of the areas where we see the most confusion in existing codebases, usually because data was cached that should not have been, or vice versa. We make caching decisions explicit and document them, so the next developer is not left guessing why a page shows stale data.

Search, performance and accessibility come easier

Because pages arrive as rendered HTML, search engines and link previews see real content without depending on client-side JavaScript. Built-in handling for images, fonts, metadata and code splitting removes a lot of routine work that otherwise gets skipped under deadline pressure. None of this guarantees a fast or accessible site, but it moves the defaults in the right direction, which is most of the battle for web development projects with real commercial goals.

When Next.js is not the right choice

We would not recommend it in every case. Some situations where another tool is a better fit:

• Heavy back-end processing. Long-running jobs, data pipelines, or complex domain logic shared across many clients usually belong in a dedicated back-end service, often in Python or Node.js, with Next.js as one consumer among several.
• Highly interactive single-screen tools. A browser-based design editor or a real-time trading interface gains little from server rendering and may be simpler as a client-side application.
• A very simple content site. If a business needs a handful of pages that a marketing team edits, a hosted website builder or a lightweight static site may be cheaper to own.
• An existing team with different expertise. If your in-house developers are productive in another mature framework, the cost of switching may outweigh any benefit.

It is also worth being aware that Next.js moves quickly. Major versions have changed recommended patterns, and keeping an application current takes steady, planned effort. That is manageable with a sensible upgrade policy, but it should be factored into the cost of ownership.

Hosting and ownership

Next.js runs well on managed platforms such as Vercel, which handle builds, previews and global delivery with very little configuration. It can also be self-hosted in containers on AWS, Google Cloud or Azure when an organisation needs everything inside its own cloud account. We choose based on compliance needs, existing infrastructure and cost at your expected scale, and we set up cloud and DevOps so that deployments are automated and repeatable whichever route you take.

The takeaway

We use Next.js by default because it lets a small team deliver fast, secure, maintainable applications with fewer moving parts. We step away from it when the problem calls for something else. If you are planning a SaaS product or a business web application and want a view on the right stack, that conversation should start with your requirements, not our preferences.