Next.js development for sites that also have to work as apps
Many projects start as public pages and later grow a login, a dashboard or a checkout. Next.js lets both live in one codebase. Here is how to judge whether it suits 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 logged-in screens can share one codebase.
Where we use it
Microsive ATS, our recruitment software, is built on Next.js with Prisma. Client websites and web apps we build use it too, and so does this site, which is built with Next.js and hosted on Vercel.
What we check
After each release we load a signed-in page and a public page and confirm each shows what it should. Caching is the reason: a page meant for one person should not be served to other visitors from a shared cache.
Signs Next.js is the right base
- Pages need to rank in search, and the same product has screens behind a login.
- Marketing pages and app screens share components and data, so one codebase avoids building things twice.
- You want the frontend and its API routes in TypeScript, in one repository.
When another choice fits better
- A handful of pages that rarely change. A static site is simpler to host and hand over, and a large framework’s upgrade work buys you little.
- Mostly long-running work. Imports, bulk emails and slow AI calls don’t belong inside page requests. They go to a queue, 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 know may serve you better.
The trade-off: Next.js moves quickly. Major versions have changed conventions and defaults, so upgrades need planned time. Its server features have long run most smoothly on Vercel. 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 until the live page shows it?
- Is authentication 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 to cache and write it down, so a stale price or stock count is a known setting. - Auth that lives only in proxy. Checks in proxy (formerly middleware) suit redirects, but data-changing handlers should check the session themselves too.
- Client components creeping upward. Marking a large parent as client-side ships its whole subtree as JavaScript to phones. Plan which parts need interactivity.
- Hydration mismatches. Dates, random IDs and browser-only APIs can render differently on server and client. Check the browser console on real pages as part of testing.
For the services built on it, see web apps and websites; the rest of the frontend set is one level up in the breadcrumb.
Planning a Next.js site or app?
Tell us what it has to do at launch and what you expect to add after. Someone from our team replies within one business day.