CodeConfig.dev: Headless WordPress With A Next.js Front End For A Plugin Company And Agency

The Challenge

This Headless WordPress project is our own website. CodeConfig began as a WordPress plugin company and grew into an agency, and the site had to grow with it. Today it carries eight products, eighteen service pages, documentation, case studies, a blog, a changelog, careers and an affiliate programme.

We wanted two things that a traditional theme makes hard to have together. The team wanted to keep the WordPress admin, because that is where our content and our habits already live. We also wanted a front end we fully control: fast, custom, and free of the scripts and styles that themes and front-end plugins add to every page. We use Next.js for exactly that reason.

What We Built

WordPress stays as the content system on its own backend domain, and a separate Next.js application renders everything a visitor sees.

• Next.js front end — every public page is rendered by Next.js, with optimised images and component-based layouts.
• WordPress as the content hub — editors work in the normal WordPress admin on a separate backend that visitors never load.
• GraphQL API — the front end reads content from WordPress through WPGraphQL, asking only for the fields each page needs.
• Custom post types and fields — case studies, services, documentation and careers each have their own structured fields, such as hero stats, results and FAQs.
• Product pages and live demos — six WordPress plugins and two Shopify apps, each with its own page, pricing and a demo.
• Docs and changelog — product documentation grouped by product, plus a public changelog.
• Lead capture — a project form with type and budget fields, and a direct booking link for calls.
• SEO managed in WordPress — titles, descriptions, social fields and a score checklist are edited per entry and output by the front end.

This case study is itself an example. It is stored as a WordPress entry with custom fields and delivered to you by the Next.js front end.

The same backend also runs our support and customer tools, so product, content and customer data live in one place while the public site stays light. Nothing a visitor loads depends on how many plugins are installed in the admin.

How The Headless WordPress Build Worked

The work followed the four steps of our Headless WordPress service.

1. Architecture and modelling — we defined the content models first: which things are post types, which fields they carry, and how they appear in the GraphQL schema.
2. API and backend setup — we configured the WordPress backend, the custom fields and the GraphQL layer, and locked the backend down since it no longer serves public pages.
3. Front-end build — we built the Next.js application and a set of shared components, so services, products and case studies all draw from one design system.
4. Deploy and operate — we connected publishing to deployment, so content saved in WordPress appears on the live site without a manual release.

A Headless WordPress setup like this splits the work cleanly. Editors publish without thinking about code, and developers change the front end without touching content.

Design

Because the front end is a custom application, the design is not limited by a theme. Service pages, product pages and case studies share the same components, spacing and type, which keeps a large site consistent. New page types are added as components, then reused wherever they are needed.

Images are resized and served in modern formats by the front end, fonts are loaded once, and pages share cached data where they can. A theme usually leaves these details to a stack of optimisation plugins. Here they are part of the build.

SEO

Search engines receive fully rendered pages with their own titles, descriptions, canonical URLs and Open Graph data. Editors control those fields in WordPress, entry by entry. Keeping SEO in the editor’s hands, while the front end handles speed, is one of the main reasons to choose Headless WordPress for a content-heavy site.