Next.js developer

What I ship

Next.js 15 with the App Router and React 19 Server Components as the front end. WordPress 6.7+ as the editorial back end, communicating over REST or GraphQL. Cloudflare Workers and Pages for the runtime and the edge cache. TypeScript across the stack. Tailwind CSS for the design system. Anthropic Claude and Model Context Protocol when AI features earn their keep.

This is not a technology list from a job ad; it is the stack I run in my own production. Every element has a reason to be there: the App Router gives per-route rendering, RSC cuts the JavaScript shipped to the client, Workers eliminate cold starts and keep data within reach of European regulation. When an element stops holding up in practice, it drops out of the stack, which I document quarterly in the Tech Radar.

When Next.js is the right choice

Personalised pages, session-driven flows, A/B-tested experiences, transactional checkout, real-time dashboards, and authenticated workspaces all benefit from the streaming SSR + RSC model. The mental model is "render close to the data, stream what is ready, hydrate what is interactive". For pages that fit, Next.js delivers a UX that classic SSR or static cannot match.

For pages that do not fit, I say so. Content-heavy marketing sites, blogs, and documentation usually win on Astro with static + ISR at lower cost. The framework decision is part of scoping, not a default. If discovery shows your site does not need Next.js, you will hear that, together with a cheaper recommendation.

Architecture: WordPress as the back end, Next.js as the front end

In a headless setup WordPress stops rendering pages and stays what it is genuinely good at: an editorial system. The content team keeps working in the familiar admin, with the same roles, workflows, and editorial plugins. Next.js fetches content over REST or WPGraphQL and renders it with a strategy matched to the route: homepage and landing pages as static with revalidation, the product catalogue as ISR with webhook-driven invalidation, checkout and the customer account as SSR with a full session.

Three elements decide whether this architecture works in practice, and all three are part of the delivery. Editorial preview: an editor has to see a draft before publishing, so I wire draft mode to WordPress instead of telling the team "that is not possible anymore". Cache invalidation: publishing in WordPress fires a webhook that revalidates exactly the routes the change touches, instead of flushing the entire cache. Media handling: images go through the Next.js pipeline with automatic AVIF and responsive sizes, regardless of what the editor uploaded.

Performance and Core Web Vitals

Performance in Next.js does not come from the framework; it comes from the architectural decisions the framework makes possible. Streaming SSR sends the first byte before the server finishes rendering the whole page, which directly lowers TTFB and LCP. Server Components keep data-fetching logic on the server, so the client receives less JavaScript and INP stops suffering from hydrating everything at once. Caching on the Cloudflare edge answers users from the nearest point of the network instead of a single origin server.

Every project starts with a baseline: TTFB, LCP, INP, and CLS measured on real users before the change, not in a lab. After the launch the same metrics are collected via RUM and compared in a side-by-side measurement window. The outcome of the project is the difference in field data, not a Lighthouse screenshot. The public Astro vs Next.js measurement protocol on WooCommerce, with the methodology open for review, is linked in the reference section at the bottom of this page.

Headless WooCommerce on Next.js

A store is the most demanding headless variant, because it combines static content with a live transaction. I render product pages and categories as ISR: as fast as static, updated by webhook whenever a price or stock level changes. Cart, checkout, and the customer account run as SSR with a session, wired to the WooCommerce Store API. Per-customer pricing, B2B discount tiers, and login-gated catalogues, the typical wholesaler requirements, stop forcing you to give up caching across the whole store, because the rendering decision is made at the route level.

On top of that comes a layer stores ask about more and more often: readiness for AI shopping agents. Clean, server-rendered HTML with correct Product and Offer schema is the entry condition for an agent to see the catalogue at all. It is the same architecture that serves fast pages to humans, so you do not pay for it twice.

SEO, GEO, and AEO in Next.js

Server-side rendering is the visibility foundation that client-side React can never provide: AI crawlers such as GPTBot, ClaudeBot, and PerplexityBot do not execute JavaScript, and Googlebot executes it with delay and a budget. Next.js with SSR and RSC returns the full content in the first HTML response, so what the user sees is also what the bot sees.

On that foundation I build the technical layer: per-route metadata API, canonical and hreflang via metadata.alternates, sitemaps via generateSitemaps, structured data as JSON-LD matched to the page type (Product, Article, FAQPage, HowTo), Open Graph with per-page generated images. For visibility in generative search I add the GEO elements: direct-answer sections, FAQs with structured data, llms.txt, and content negotiation for agents. Every project goes through a 30-point SEO checklist before the DNS cutover.

Security and EU jurisdiction

Headless shrinks the attack surface in a way you can explain to a board in one sentence: WordPress disappears from the public internet. The login panel, XML-RPC, and plugin files stop being reachable by scanners, because Next.js serves the front end and the origin is accessible only to it. Add centrally configured security headers, server-side input validation, and secrets kept out of the repository.

For companies covered by GDPR, NIS2, or DORA, data geography matters too: a Cloudflare runtime with EU processing, data processing agreements in Polish or English, and documented data flows for the record of processing activities. A B2B contract in European jurisdiction, not the terms of service of a platform outside it.

Who this is for

• WooCommerce stores with custom checkout flows or per-user pricing
• SaaS dashboards and authenticated workspaces backed by WordPress as a content layer
• Multi-region brands needing ISR with webhook-driven invalidation
• Editorial publishers with live data feeds, comments, or real-time analytics surfaces
• B2B wholesalers with login-gated catalogues and pricing negotiated per account

Engagement model

Senior B2B contracts in EU jurisdiction. Four phases: discovery with a content audit and performance baseline, scoping with per-route rendering decisions, an iterative build with weekly demos and a side-by-side measurement window, and finally tuning and retainer with observability and quarterly stack reviews. Fixed-scope or time-and-materials engagements. Pricing is individual, with a per-phase schedule and decision points.