On this page3 sections
First published January 2023. Rewritten in May 2026.
I picked Next.js as the single web framework I build on in February 2022. Four years later it's the layer underneath antondevilliers.com, BX1X, Authentikor, and the SEO AI Toolbox used to plan and produce 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:
- Marketing and content sites. This site is one. Blog pages are statically generated from Markdown, structured data is injected per page, and the sitemap is generated automatically. Other routes use the render mode their data needs.
- Business apps. BX1X is a 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.
- 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.
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 supports the business outcome, 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. Tell me the problem. For AI-app-related stack work specifically, see AI app development.
For your technical person
What the framework contributes to search eligibility. The Cape Town page is a Next.js page. A related case study records a manually observed first-page result for "custom software developer Cape Town" in May 2026. That observation is historical, not a claim of a current position. The framework helps with the technical baseline, while relevance, first-hand evidence, links, competition, and user value determine whether a page can compete: render mode is selected per route, so static or server-rendered routes can provide HTML without requiring a browser to assemble the whole page from a JavaScript shell; per-page metadata and accurate structured data are straightforward, since the blog renderer at pages/blog/[slug].js injects JSON-LD appropriate to the page without a plugin or a separate build step; next-sitemap regenerates the sitemap on every build and respects per-route priority and changefreq overrides (a sitemap supports discovery, it does not set rankings or guarantee indexing); and next.config.js redirects() handle 301s without touching application code. Other frameworks and CMSs can achieve the same outcomes. Next.js is a good fit here because it keeps rendering, routing, metadata, and the application surface in one codebase.
Technical detail (the four render modes). In one Next.js page file you decide, per route: server-side render (getServerSideProps), rendering fresh on every request, used when the page depends on per-request data (logged-in users, fresh stock counts); static (getStaticProps + getStaticPaths), rendered at build time, used for content that does not change per request (blog posts on this site are static); incremental static regeneration, rendered at build time and refreshed on a TTL or a webhook, used for content that changes occasionally but not per request (product detail pages); and client-side, fetched and rendered in the browser after the initial HTML loads, used 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 (proxy.js in this codebase) gives you a fifth surface: code that runs at the CDN edge before the page is rendered. This site uses it to strip UTM parameters and handle /amp redirects.
Speed and technical SEO capabilities. The "Next.js is fast" claim is true but understated. The speed comes from three places, not one: a fitting render mode, so a page can provide useful HTML early when its data and route design allow it (this helps accessibility and crawlability, but it does not decide relevance or authority); per-page bundles, so a marketing page does not download the entire admin app's JavaScript, which Next.js does automatically; and built-in image optimisation (next/image), which serves WebP, picks the right resolution, and lazy-loads off-screen images, the same for fonts (next/font), where the layout-shift cost of remote fonts goes to zero. The SEO claim is similarly bounded. Next.js can provide rendered HTML for crawlers, per-page metadata, and clean structured-data injection. None of that is unique to Next.js, and none of it guarantees indexing or ranking. It is simply a practical technical foundation for a content or application surface.
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.
Questions owners ask
Is this site you are reading built on Next.js?
Yes. antondevilliers.com runs on Next.js. The blog post you are reading is statically generated from a Markdown file in _posts/, with structured data injected at the page level. The page-render code is in pages/blog/[slug].js. This site is the demo.
Why Next.js over plain React or a CMS like WordPress?
Plain React gives you the UI but not the rendering, routing, or API layer, you bolt those on. A CMS gives you content management but not the structured-data control, page-level performance, or the freedom to add a real API surface in the same codebase. Next.js gives you the React UI, the page-level rendering control (server, client, static, edge), and a Node API surface in one repo. For the kind of work I ship, that is the cleanest answer.
Does the stack matter for ranking in Google or LLM answers?
The stack can support crawlable rendered HTML, per-page metadata, structured data, and performance, but it does not create relevance, authority, or rankings by itself. Next.js supports static, server, client, and edge rendering per route. A related case study records a manually observed first-page Cape Town result from May 2026, not a current-rank claim or a promise for another site.