Next.js development for a public site and an app in one codebase
Plenty of projects start as a few public pages and later need a customer login, a portal or a dashboard. Next.js holds both in one codebase. Here is how to judge whether it fits yours.
Reviewed by: Rahul Jaiswar, founder
Next.js in two sentences
Next.js is a React framework maintained by Vercel. It adds routing, server rendering, data fetching and a build system on top of React, so public pages and screens behind a login can share one codebase.
Is Next.js a good fit for a site with a customer portal?
Yes, when the public pages need to be found in search and the portal shares their data and components. A 3PL’s marketing pages and the screen where its clients check open orders can then live in one repository, written in TypeScript end to end, instead of two projects built twice. If the portal is the whole product and nobody needs to find it through search, a simpler React setup may do.
Where we use it
Microsive ATS, the recruitment software we built and run, is built on Next.js with Prisma. Client websites and web apps we build use it too, and so does this site.
What we check
After each release we load one signed-in page and one public page and confirm each shows what it should. The reason is caching: a page meant for one signed-in user must never be served to anyone else from a shared cache.
When another choice fits better
- A handful of pages that rarely change. A static site is simpler to host and to hand over, and a large framework’s upgrade work gets you very little.
- Mostly long-running work. Nightly imports from a warehouse system, bulk emails and slow AI calls don’t belong inside a page request. They go to a background worker, and Next.js shows the results.
- An in-house team that works in Laravel or Django. If they will maintain the product, a framework they already know may serve you better.
The trade-off: Next.js moves fast. Major versions have changed conventions and defaults, so upgrades need time set aside. Its server features have long worked best on Vercel’s own hosting. Next.js 16 added an adapters API (initially alpha) so other hosts can support those features, and a static export runs anywhere with some features dropped.
Questions to ask a team building with Next.js
- Which pages render on the server, which are static, and why?
- After a content edit, how long before the live page shows it?
- Is sign-in checked inside server actions and route handlers, or only in proxy (formerly middleware)?
- What is the plan for the next major version?
Where Next.js projects go wrong
- Caching defaults. They have changed between major versions. In Next.js 16, caching is opt-in through Cache Components and the
use cachedirective. Decide per page, component or data function what gets cached and write it down, so a stale stock count or rate is a known setting, not a surprise. - Sign-in checked only in proxy. Proxy (formerly middleware) is fine for redirects, but any handler that changes data should check the session itself too.
- Client components creeping upward. Marking a large parent component as client-side sends its whole subtree to the browser as JavaScript. Decide which parts actually need to be interactive.
- Hydration mismatches. Dates, random IDs and browser-only APIs can render one way on the server and another in the browser. Check the browser console on real pages as part of testing.
For the work built on it, see software and web apps.
Planning a Next.js site or app?
Tell us what it has to do at launch and what you expect to add later. Someone from our team replies within one business day.