Process: 02Next.js renderServer components, cached by tag
Process: 03Store API callCatalogue, cart, and checkout
Store: 04WooCommerceStill the commerce system of record
Output: 05PageInvalidated by tag when content changes
WordPress keeps the commerce; it stops rendering the pages.
The problem
A WordPress theme rendered the storefront, which made every page slow and every change a theme change. Replacing the front end took a few weeks. The harder part was that a store taking real orders cannot run on undocumented knowledge in one person's head.
What I built
A Next.js App Router front end over the existing WooCommerce install, talking to it only over the REST and Store APIs. WordPress keeps the catalogue, orders and content, and stops deciding what a page looks like.
The few behaviours that have to run server-side live in must-use plugins on the backend, versioned alongside the front end because the two are a matched pair.
I treated the documentation as part of the work: an architecture write-up, an environment and secrets matrix, runbooks for deploy, rollback and incident response, and append-only decision records that say why. Reverse a decision and you write a new record superseding the old one. You do not edit the history.
CI runs lint, typecheck and build on every pull request, and a production guard refuses to boot if TLS verification has been switched off, which is the local workaround that must never reach production.
Error tracking, performance monitoring and rate limiting went in before launch instead of after the first incident.
A phased roadmap with per-phase status, so nobody confuses what is done with what happens to work in dev.