We run several SaaS products and this website on the Next.js App Router. innopulse.io itself generates over 1,500 pages statically at build time, bilingual, with structured data and automated checks. This article summarises which patterns have held up in production with Next.js 15 and where teams typically lose time and security.
Server Components as the default
In the App Router, components are Server Components by default: they run on the server, access data directly and send no JavaScript to the browser. Client Components are only needed where interaction happens — stateful forms, menus, charts. The most important rule is to draw the boundary deliberately: a “use client” high up the tree turns everything below into client code and throws the advantage away. Building pages as Server Components with small interactive islands has worked well.
Server Actions are public endpoints
Server Actions feel like function calls but are technically HTTP endpoints anyone can call who knows their identifier. The same duties follow as for any API: validate input, for example with a schema, check authentication and authorisation on every call, enforce tenant boundaries server-side and return errors in a controlled way. A Server Action that only checks whether a button was visible in the frontend is a security hole.
Caching under the new defaults
Next.js 15 reversed the caching defaults: fetch requests, GET route handlers and the client-side router cache for pages are no longer cached by default. That removed many surprises of earlier versions in which data was unexpectedly stale. In return, caching must now be switched on deliberately where it makes sense: static content through static generation, expensive queries through targeted revalidation. Newer versions continue towards explicit control; teams caching deliberately today are well prepared for that.
Async request APIs
In Next.js 15, cookies(), headers(), params and searchParams are asynchronous. That is a nuisance during migration but consistent: it makes visible which parts of a page depend on the request and therefore must render dynamically. To keep a page static, avoid these APIs there and isolate the dynamic parts.
Integrating Supabase auth properly
With Supabase the session runs via cookies. A server client reads them in Server Components, Server Actions and route handlers, and middleware refreshes the session on each request. For authorisation decisions on the server, verify the user against the auth service rather than blindly trusting a locally read session. The real safeguard, though, is in the database: with row-level security, tenant isolation holds even if a check is missing in application code. More in our Supabase data residency playbook.
Static generation at scale
For content that does not change per request, static generation with generateStaticParams is the most robust choice: fast, cheap, good for search engines. We generate glossary, guides, comparisons and regional pages in two languages this way. Two things matter. First, honest hreflang: a page that exists only in German returns a real 404 in English rather than a false alternate. Second, an automated post-build check that every sitemap URL exists, has a correct canonical and is linked internally. Without it, errors grow unnoticed with the page count. The content side is covered in our article on topical authority.
Hosting region and data residency
On Vercel, server functions run in a US region unless configured otherwise. Anyone processing personal data from the EU or Switzerland should deliberately place the function region close to the database, for example in Frankfurt. That also cuts latency, because otherwise every database query crosses the Atlantic twice. The underlying question of location is covered in our decision guide Swiss hosting or EU hosting.
Updates are operations, not optional
Framework updates are part of operations. At the end of 2025, a critical security vulnerability in React Server Components forced many Next.js projects to update at short notice. Teams maintaining dependencies regularly do such updates in minutes; teams freezing versions for months face a migration under time pressure. Automatic security-update alerts and a pipeline with tests make the difference; see CI/CD.
The most common mistakes
- Client Components too high up the tree, shipping unnecessary JavaScript.
- Server Actions without validation and without authorisation checks.
- Caching by feel instead of a deliberate decision per data source.
- The database service key in code that ends up in the browser.
- Server functions in a different region from the database.
- No automated post-build check for large sets of static pages.
Perspective
The App Router is ready for production but requires a clear mental model: server first, client only where needed, treat every Server Action like an API, cache deliberately, keep data in the right region. We implement these patterns in our own products and for clients, for example in our fixed-price Next.js web app offer or our multi-tenant SaaS architecture.