React or Next.js for a business web application

If you are commissioning a web application, a developer may ask whether to build it with React or Next.js. It sounds like a big technical decision. It is a real one, but the trade-offs are easy to follow once you know what each tool is. This post explains React vs Next.js in plain terms for the person paying for the project, not the person writing the code.

We build with both. This site and the console behind it run on Next.js. The tablet menus we build for restaurants are a plain React app. Here is how we choose.

What each one is

React is a library for building user interfaces. It handles what appears on screen and how it changes as people click and type. On its own, it doesn't decide how pages are loaded, how URLs work or how the app talks to a server.

Next.js is a framework built on React. It adds those missing pieces: routing between pages, rendering pages on the server, loading data, and a place to put server code. Other React frameworks exist too, such as React Router in framework mode.

The React team itself now recommends starting new apps with a framework for most projects, while still supporting a plain setup with a build tool such as Vite.

So the real question is usually: a plain React app, or React inside a framework?

When a plain React app is enough

A plain React app, often built with Vite, loads in the browser and talks to a separate API. It fits well when:

• Everything is behind a sign-in. Internal tools and dashboards don't need search engines to read their pages.
• The app is highly interactive. Think scheduling grids, editors or tablet apps where the screen changes constantly.
• There is already a back end, or the back end is a separate service by design.
• Hosting should be simple. The front end is just static files that any host can serve.

Our tablet menus are a good example. The menu runs on a tablet locked to the app, needs no search traffic, and works offline. So a plain React app suits that.

When Next.js earns its place

In a business application, Next.js shines when:

• Public pages need to be found in search. Marketing pages, a blog, product or listing pages and documentation are rendered on the server, so search engines and link previews see real content immediately.
• First load speed matters. Server rendering shows content before all the JavaScript arrives, which helps on slower phones.
• You want the front end and server code in one project. Forms, data loading and small APIs can live alongside the pages, which keeps a small team moving fast.
• The product mixes public and private screens. A public site, a sign-up flow and a signed-in app can share one codebase.

This site is a good example: public service pages, a blog that needs to be found in search, and an internal console behind a sign-in, all in one Next.js project.

The costs of a framework

Next.js does more, so it asks more:

• More to understand. Server and browser code live side by side, and mistakes about which runs where cause bugs.
• Hosting choices matter more. It works best on hosts that support its server features. It can be self-hosted, but that takes more setup than serving static files.
• Faster-moving conventions. Frameworks change their recommended patterns more often than libraries do, so upgrades take planning.

None of these are reasons to avoid it. Instead, they are reasons to choose it on purpose.

What matters more than React vs Next.js

For a business application, these decisions matter more than the framework choice:

1. The data model. A database designed around the questions your business asks lasts longer than any front-end framework.
2. Who owns the code and the hosting account. You should, from day one.
3. Documentation and handover. Another developer should be able to pick up the project without calling anyone.
4. Tests on the parts that handle money and permissions.

A well-built plain React app beats a messy Next.js app, and the reverse.

A quick guide

• Signed-in tool or dashboard only: plain React, with a separate API.
• Public site plus signed-in app: Next.js or a similar framework.
• Content that must rank in search: a framework with server rendering.
• Offline-first tablet or kiosk app: plain React, often packaged for the device.

Our web applications page covers how we build and hand over projects like these.

Ask us which fits

Tell us who uses the application, whether any of it is public, and what it connects to. We reply within one business day with a recommendation and the reasons for it. Get in touch.

Cover photo by Florian Olivo on Unsplash.