Why teams choose Next.js
Next.js adds the parts of a production website that React leaves open: routing, rendering, data loading, image and font handling, and a place to write server code beside the interface. That removes a lot of glue work and gives a team one way to do each job.
- Server and static rendering. Pages arrive as finished HTML, so content shows quickly and crawlers read it without running scripts. Each page can be built ahead of time, regenerated on a schedule or rendered on every request.
- File-based routing. Folders become URLs, with shared layouts, loading states and error screens at every level.
- Performance tooling. Automatic code splitting, image optimisation, font loading and streaming of the slow parts of a page.
- Search friendliness. Page metadata, sitemaps, alternate-language links and structured data are generated on the server with the page.
- One codebase for pages and APIs. Route handlers and server functions sit next to the pages that call them, all in TypeScript.
None of this makes a slow product fast on its own. Speed still depends on image sizes, third-party scripts and database queries, which is why web platform cost drivers matter as much as the framework choice.
When Next.js is the right choice
- Marketing and content sites that must be found in search and load quickly in two languages.
- Customer portals and dashboards that mix public pages with signed-in areas.
- SaaS products and online stores, where search-facing pages and application screens belong in one codebase.
- Teams that already work in React and TypeScript and want to keep one skill set.
When another tool fits better
- A small brochure site that one marketer edits every week. A visual builder such as Webflow may ship sooner and be cheaper to maintain.
- A product that is mainly a mobile app. Build the app first; a Next.js site can follow for marketing and sign-in.
- Heavy real-time or long-running back-end work. Next.js can front it, but queues, streaming protocols and batch jobs belong in separate services.
- A team with no React experience and a short deadline. The learning cost is real, and it lands on the schedule.
Rule of thumb: choose Next.js when a site needs to be found in search, load fast on mid-range phones and carry application logic. If it needs only one of those, a lighter tool may do.
How we structure a Next.js project
Every project begins with a threat review, and the structure below follows from it. This is our method for the products we build; the details change with the product. The wider service is described on our web development page.
App Router and server components
We use the App Router. Components render on the server by default, which keeps data access, secrets and heavy libraries out of the browser bundle. We mark a component as a client component only when it needs state, effects or browser APIs, and we keep those at the leaves of the tree.
Data and caching
For each page we decide whether it is static, regenerated or rendered on every request. Caching defaults have changed between framework versions, so we write the intent down (what is cached, for how long, what clears it) and test it rather than rely on defaults. Reads go through a small data layer that also checks permissions, so a page cannot fetch what the user may not see.
Bilingual and right-to-left
The language is part of the route, for example /en and /ar. The lang and dir attributes are set on the document, layouts use logical CSS properties (start and end, not left and right), and each language has its own metadata and alternate-language links. Arabic fonts, line heights and numerals are tested, not assumed. The guide to bilingual Arabic and English products goes deeper.
Testing and deployment
Type checks, linting, unit tests for logic and end-to-end tests of the key flows, such as sign-in and forms, run before every release. We deploy to Vercel or to another host, such as AWS, Azure, Google Cloud or a container platform, depending on where your data and requirements sit. Preview deployments let you review each change in the weekly demo.
Security points specific to Next.js
Next.js moves code between the server and the browser, which creates failure modes that older sites did not have. A secure-by-default setup covers each of them. Our secure-by-default web checklist lists the wider basics.
| Area | What to do | Common mistake |
|---|---|---|
| Headers and content security policy | Send a content security policy, HSTS, a content-type option, a referrer policy and frame restrictions. Start in report-only mode, then enforce. | Adding a policy once with broad exceptions and never tightening it. |
| Server actions and route handlers | Treat each one as a public endpoint: authenticate, authorise and validate input against a schema on the server. | Assuming the form on the page is the only caller. |
| Secrets and environment variables | Keep secrets server-side and separate per environment. Only variables with the public prefix are sent to the browser. | Putting an API key in a public variable just for now. |
| Data passed to client components | Pass only the fields a component displays. | Sending a whole database record as props, which ships hidden fields inside the page. |
| Authorisation | Check access in the data layer, not only in a request-level redirect. | Protecting a whole area with one middleware rule. |
| Dependencies | Use a lockfile, scan in CI and upgrade the framework and packages regularly. | Staying on an old release because it works. |
A content security policy is the main browser-side defence against injected scripts. A policy that uses a fresh nonce for every request needs those pages rendered per request, which affects static caching, so we settle that trade-off early.
Framework advisories in the past have shown that request-level checks can be bypassed, which is the reason to authorise at the data layer as well. Before launch there is a security review with a prioritised fix list, and deeper assurance is covered under cybersecurity.
Questions to ask any Next.js team
- Which pages are static, regenerated and rendered per request, and why?
- Where is authorisation enforced, and is it tested?
- How are secrets handled across development, staging and production?
- What happens to Arabic layout, fonts, metadata and search in the right-to-left version?
- Who upgrades the framework and the dependencies, and how often?