Headless CMS vs visual CMS vs the middle path
Honest comparison of three content management approaches for small agencies: headless CMS, visual page builders, and the middle path that keeps structure in code.
This is how we think about CMS choices for small-to-mid-sized agencies.
TL;DR. Headless CMSes give designers freedom but drop SMB editors into unfamiliar admin UIs. Visual page builders feel friendly to editors but hand the rendering layer to the platform and invite clients to break the design. The middle path keeps structure in code (the agency’s strength) and constrains editing to defined fields (the client’s domain) - it fits agency portfolios of many similar SMB websites better than either extreme.
TL;DR (skim view)
- Headless CMS offers total design freedom but leaves SMB editors lost.
- Visual page builders are easy for clients but risk breaking the design and limit performance.
- The middle path keeps structure in code and restricts edits to defined fields, which in our experience works best for managing multiple similar sites.
Every web agency that has been around for a few years has a CMS conversation that goes roughly like this. The client wants to edit content themselves. The designer wants the design to stay intact. The developer wants something they can deploy and forget. Picking a CMS is picking which of those three you are willing to compromise on.
The market is often framed around two answers - headless CMSes and visual page builders - and there is a third path between them that gets less press but probably fits more agency portfolios.
Headless CMS
A headless CMS is a backend-only content repository that delivers structured data via an API, leaving the frontend rendering entirely to the developer.
A headless CMS is a content store with no presentation layer. The content is structured (typed fields, relationships, locales). The frontend is your problem. You build it in whatever framework you like; it talks to the CMS over an API.
Examples: Sanity, Contentful, Strapi, Storyblok, Hygraph, Caisy.
What it gets right: complete design freedom. The content is structured, so the frontend can render it however the design demands. Versioning, drafts, localisation, audit logs - all the developer-facing primitives are there.
What it gets wrong for the SMB editor: the editor experience varies wildly. Some headless CMSes have a polished editor (Sanity Studio, Storyblok). Others are raw schemas with admin scaffolding (Strapi, the developer-oriented end of the market). For an SMB editor who has used WordPress for ten years, the unfamiliar admin can be a real friction.
Who it fits: agencies that have a strong frontend team, work with clients who have technical staff, and need maximum design freedom. It has been the right answer for most “premium” agency work we’ve seen and most product-marketing sites.
Visual page builder
A visual page builder is a low-code tool that lets editors drag and drop elements to compose pages, but relies entirely on the platform’s proprietary rendering engine.
A visual page builder lets the editor compose pages by dragging blocks onto a canvas. The result is rendered by the platform itself - the agency does not own the rendering layer.
Examples: Wix, Squarespace, Webflow, Elementor (a WordPress plugin), Duda.
What it gets right: editors love it. Drag, drop, change a colour, see the result. No mental model of “structured content” required.
What it gets wrong for the agency: you do not own the design system. Clients can move sections, change colours, override fonts, and break the design in ways that are immediately visible. The agency ends up doing recurring “design recovery” work, or locking down the editor heavily, which defeats the point of using a visual builder in the first place.
What it gets wrong technically: the rendering is the platform’s. Performance (as noted in the Web Almanac performance report), accessibility, and SEO all depend on choices the platform made. Migration off the platform is hard.
Who it fits: very small projects where the client is the designer, or where the agency is happy to outsource the rendering layer in exchange for editor self-service. Often the right answer for a single-person business that wants to manage their own site without hiring an agency at all.
The middle path
The middle path is a hybrid approach where the agency strictly defines the content structure in code, while the CMS provides a polished interface for clients to edit only those allowed fields.
The middle path keeps structure in code (the agency’s strength) and content in the CMS (the client’s domain). The editor is constrained: clients edit only the fields the agency exposed. They cannot reorder sections, swap fonts, or break the design - but they can change the photo, edit the copy, add a FAQ entry, publish.
Examples: In our experience, this is what Kernset is built to be. See the Kernset features for the full block list. Other examples in the space include Statamic (PHP), Tina (open-source), and parts of Sanity Studio when used with strict schemas.
What it gets right: the editor experience is polished (because the agency built only the fields that matter), the design is locked in code (because the structure is not editable), and the rendering layer is whatever the agency chose. It is the closest to “WordPress that does not break” you can get without being WordPress.
What it gets wrong: less design freedom for the editor. If a client says “I want this section to look completely different on this page,” the answer is “we can build a new block type for that, but it will be a small project.” Visual page builders absorb that request without scoping work.
Who it fits: agencies that maintain many similar client websites - hotels, clinics, local services, restaurants - where the design system is fairly consistent, the clients are not designers, and the goal is to lock the design and let clients edit content. The middle of the agency portfolio.
Side-by-side decision table
| Concern | Headless CMS | Visual page builder | Middle path |
|---|---|---|---|
| Design freedom for the agency | High | Low | Medium |
| Design freedom for the client | None | High | Limited to defined regions |
| Editor familiarity for SMB clients | Varies | High | Medium-high |
| Rendering layer owned by | The agency | The platform | The agency |
| Risk of client breaking design | Low | High | Very low |
| Per-client recurring cost | Medium | Low to medium | Low |
| Multi-tenant ergonomics | Varies (often per-project setup) | One platform account per client | Built-in |
| Best for | Premium / product sites | Single-person businesses | Mid-size agency portfolios of similar SMB sites |
How to actually decide
If you find yourself asking these questions, the right answer is usually one of:
-
“My clients keep breaking the design.” You are on the wrong side of headless or visual. Move to the middle path.
-
“My clients keep needing different layouts per page.” Visual page builder is closer to what you need - or you need a richer block library on a middle-path CMS.
-
“My designer wants total freedom and the client only edits text.” Headless CMS, polished editor (Sanity Studio is the typical choice).
-
“I have many similar clients and I want one admin for all of them.” Middle path with multi-tenancy. Kernset.
Where Kernset sits
In our experience, Kernset is the middle path with multi-tenant administration. Block schemas live in TypeScript (the agency’s repo), the editor renders against those schemas (clients see only the fields the agency exposed), and the customer site can be hosted anywhere - cheap shared host, Vercel, or self-hosted Node. One admin handles every client website.
It is not for everyone. If your portfolio is two design-heavy product sites, headless plus Sanity Studio is probably a better fit. If your portfolio is fifty very similar SMB sites and you want them all under one admin, we’ve seen that the middle path is exactly the right tool.
Frequently asked questions
Which CMS is best for a small web agency?
The best CMS depends on the agency’s typical client. For premium, highly custom product sites, a headless CMS is often the best fit. For one-off, low-budget sites where the client acts as the designer, visual page builders win. For an agency managing dozens of similar SMB websites where design consistency is critical, a middle-path, block-based CMS is usually the most sustainable choice.
Can you use Kernset as a headless CMS for a custom Next.js project?
Yes. The cached-static and self-hosted-Node hosting modes are exactly that. The content lives in Kernset, the customer Next.js app fetches it. The constraint is that block schemas live in your code (not in a Sanity-Studio-style “schema” UI in the admin) - which is the design choice that makes the middle-path UX work.
Is the middle path just headless CMS with stricter schemas?
In one sense, yes. The difference is that Kernset assumes you ARE going to define block schemas in code, and shapes the editor experience around that. A pure headless CMS with strict schemas can land in roughly the same place, but you build the editor polish yourself.
Why not give clients a visual page builder for the parts that need flexibility?
You can. Kernset’s flexible content zones let clients add and reorder blocks within a designated region, drawn from an allowlist the agency defines. It is not a full visual page builder - the allowlist constrains what they can add - but it gives editors meaningful structural control without exposing the layout grid.
See it against your portfolio
If you are still weighing headless against visual against the middle, the fastest way to settle the question is to look at Kernset side-by-side with two of your trickiest client websites. Get early access - a real person reads every message.