Next.js: The Stack the AI Pipelines Run On

I picked Next.js as the single web framework I build on in February 2022. Three years later it is the layer underneath antondevilliers.com, BX1X, Authentikor, and the SEO AI Toolbox that ranks pages and produces content.

This post is the reasoning. Most of it still holds. The parts that have changed are flagged.

What I was looking for

By 2022 I had been running React for the front end and Node for the API for years, in two repos with two deploy pipelines and two sets of types. The friction was constant. Either the front end and the API were out of sync, or the developer experience was worse than it needed to be, or the build pipeline did three things instead of one.

What I wanted in one stack:

• React UI - already the front-end foundation
• A real Node API surface - not just routes-as-an-afterthought
• Page-by-page rendering control: server, client, static, or edge depending on what the page needs
• A built-in story for SEO and structured data
• A single deploy

Next.js was the only thing that gave me all of those without bolting frameworks together.

What I actually use it for

Three shapes of work, all on the same stack:

1. Marketing and content sites. This site is one. Pages rendered server-side from Markdown, structured data injected per page, sitemap generated automatically. Predictable lighthouse scores.
2. Business apps. BX1X is a 37+ module business operations platform on Next.js - billing, bookings, CRM, accounting, inventory, e-commerce, all in one app surface. Authentikor (my own SaaS) runs on the same stack.
3. Custom dashboards over a real Node API. When the work is heavy enough that the Next.js API routes would block the request thread, I run a separate Node.js API server alongside (Express, sometimes more specific) and let Next.js handle the rendering and the lighter routes. This is the pattern in the Node.js + PostgreSQL reporting case study.

The split between Next.js API routes and a separate Node service is the one thing I think most teams get wrong. Use Next.js routes for what is fast (auth, simple CRUD, server actions). Run a real Node server for what is slow (warehouse refreshes, third-party API joins, anything that needs a queue). One repo can hold both, deployed separately.

Why it ranks

The cape-town page that holds first-page Google for "custom software developer Cape Town" is a Next.js page. It ranks because the engineering is right (proof-first content, schema, internal links - see the case study for the full recipe), but the stack does the heavy lifting on the technical side:

• Server-side rendering by default. Crawlers see HTML, not a JavaScript shell. Same for LLM crawlers (ChatGPT, Claude, Perplexity, Gemini).
• Per-page meta and structured data are trivial. The blog renderer at pages/blog/[slug].js injects four JSON-LD blocks (BreadcrumbList, BlogPosting, FAQPage, ProfessionalService where applicable) without a plugin or a build step.
• next-sitemap regenerates the sitemap on every build and respects per-route priority and changefreq overrides.
• next.config.js redirects() handle 301s without touching application code.

CMS-based sites have to bolt all of this on through plugins. Next.js gives it as default behaviour.

Technical detail (the four render modes)

In one Next.js page file you decide, per route:

• Server-side render (getServerSideProps) - render fresh on every request. Use when the page depends on per-request data (logged-in users, fresh stock counts).
• Static (getStaticProps + getStaticPaths) - render at build time. Use for content that does not change per request. Blog posts on this site are static.
• Incremental static regeneration - render at build time, refresh on a TTL or a webhook. Use for content that changes occasionally but not per request (product detail pages).
• Client-side - fetch and render in the browser after the initial HTML loads. Use for interactive widgets and dashboard panels.

You pick per page, in the same file, with the same component code. Most React+Express setups force a single mode site-wide.

Edge middleware (middleware.js) gives you a fifth surface - code that runs at the CDN edge before the page is rendered. I use it for geo-aware routing, A/B test assignment, and auth checks where the answer needs to be cached at the edge.

Speed and SEO, by default

The "Next.js is fast" claim is true but understated. The speed comes from three places, not one:

• Server-render where possible, so the browser receives HTML with content already in it. First paint happens at HTTP response time, not after a JavaScript bundle parses.
• Per-page bundles, so a marketing page does not download the entire admin app's JavaScript. Next.js does this automatically.
• Built-in image optimisation (next/image), which serves WebP, picks the right resolution, and lazy-loads off-screen images. Same for fonts (next/font) - the layout-shift cost of remote fonts goes to zero.

The SEO claim is similarly understated. Next.js gives you fully rendered HTML for crawlers; it gives you per-page meta control; it integrates cleanly with structured-data injection. None of that is unique to Next.js, but Next.js is one of the few stacks where it is the default.

What I would change in 2026

The original 2023 post argued for Next.js as a "great framework". I would frame it differently now: the right framework when the same team writes the UI, the API, and the SEO surface, and wants one repo and one deploy. That is most of what I build.

If the project is purely a content site with no real API and no logged-in users, Next.js is overkill - Astro is lighter, sometimes Eleventy is enough.

If the project is a heavy SaaS with a complex API and the front end is a thin shell, a separate Node API server with React on top is fine - Next.js does not have to be the framework.

For everything in between (which is most business software), Next.js is still the answer. It is the stack underneath this site, BX1X, Authentikor, and the SEO AI Toolbox.

When the stack matters in the engagement

I do not lead with stack on a sales call. The buyer cares about whether the work ships and whether it ranks, not whether it is React or Vue underneath.

Where the stack does matter is the day the project gets handed off, scaled, or extended. A single repo, a single language (TypeScript top to bottom), a single deploy pipeline - those compound. Polyglot setups look pragmatic on day one and become brittle by year two.

If you have a project where the existing stack is the bottleneck (slow CMS, brittle plugins, sync issues between the front end and the API), the conversation starts with what the system needs to do, not which framework. Get in touch. For AI-app-related stack work specifically, see /services/ai-app-development. Past project work is on /projects.