WordPress powers around 40 percent of the web. That statistic is impressive and slightly alarming. It means that nearly half of all websites are running on software originally built for blogging in 2003, carrying two decades of decisions made under completely different constraints.
We used WordPress. Most agencies did. Then we stopped.
The problem with WordPress
WordPress is not bad software. It does what it was built to do. The problem is what it became — a platform stretched to cover every use case, held together by plugins, and requiring constant maintenance to stay secure.
The average WordPress site runs fifteen to thirty plugins. Each plugin is a dependency. Each dependency has a maintainer who may or may not ship updates. When a security vulnerability is disclosed — and they are disclosed regularly — you need to update everything quickly or leave a door open. Most small business owners do not know this is happening. Most agencies do not tell them.
The update anxiety is real. The performance overhead is real. The database queries per page load are real. We decided to solve the problem at the source rather than manage it indefinitely.
What a headless CMS actually is
A traditional CMS like WordPress handles two things: storing your content and displaying it. These two concerns are coupled. The display layer (your theme) is tied to the storage layer (WordPress). Change one and you affect the other.
A headless CMS handles only storage. It holds your content and exposes it via an API. A separate application — in our case an Astro site — requests that content and decides how to display it. The two layers are independent.
This sounds like added complexity. In practice it is the opposite. The CMS does one thing and does it well. The front end does one thing and does it well. There are no plugins bridging the gap between them.
Why Sanity specifically
Several headless CMS platforms exist. We chose Sanity for three reasons.
First, the content model. Sanity treats content as structured data, not as pages. A blog post is not a blob of HTML — it is a document with typed fields: a title string, a publish date, an array of body blocks, a reference to an author. This structure means the same content can appear in multiple contexts without duplication. Change the author's name in one place and it updates everywhere it is referenced.
Second, the Studio. Sanity's editing interface is a React application that you configure in code. It is not a black box — it is exactly the fields you define and nothing more. Editors get a clean, fast interface that reflects the structure of the content. There are no irrelevant settings, no plugin menus, no theme options that do not apply.
Third, GROQ. Sanity's query language lets you ask for exactly the data you need and nothing else. A page that only needs a list of post titles and slugs gets exactly that — not the full document including body content. This precision has a direct impact on page load times.
Real-time collaboration
Sanity's Studio supports real-time collaboration. Two editors can work on the same document simultaneously and see each other's changes. There are no overwrite conflicts. For teams, this removes the coordination overhead that comes with traditional CMS publishing workflows.
How Forge uses it
Every site we build runs on Sanity. The content schema is defined in code alongside the front end — it lives in the same repository, is reviewed in the same pull requests, and is deployed with the same pipeline.
When we launch a new client site, we seed it with real content from day one using Sanity's import tools. The client gets a live site with real data on launch day, not a blank CMS they have to fill in themselves.
The Studio is branded per client. They log in to a clean interface that shows only the content types relevant to their site — no global settings they should not touch, no fields that do not apply to their content. It is their CMS, built to their content model.
When Sanity is overkill
Not every project needs Sanity. A single-page marketing site with no content that changes does not need a CMS at all. A personal blog with one author updated monthly could run on a simpler setup.
Sanity earns its place when content volume is significant, when multiple editors need access, or when the same content needs to appear in multiple places. For any business website that will grow — more pages, more team members, more content types — it is the right foundation.
The free tier covers most small projects. Paid plans scale with team size and API usage. We have never had a client outgrow the free tier in the first year.
The maintenance question
Sanity is maintained by Sanity. Security updates, infrastructure, uptime — their responsibility, not yours. There are no plugins to update. There are no vulnerabilities introduced by a third-party author who abandoned their project in 2019.
Your site still requires maintenance — dependencies update, content models evolve, new features get added. But the category of problems that come from running your own database-backed CMS on shared hosting disappears entirely. That is worth a lot.