# Do You Still Need a CMS After Leaving WordPress?

> By Lawrence Arya, Founder, WPBuildAI. Published 2026-09-03. 10 min read. Guides.
> Source: https://wpbuildai.com/blog/do-you-still-need-a-cms-after-leaving-wordpress/
> Language: en

A content management system is not a website requirement. It is a workflow tool, and workflow tools should match the volume of work.

**TL;DR.** Publishing frequency decides it. Under one change a month, a CMS is overhead you maintain for nothing and direct edits are cheaper. One to four changes a month, a lightweight git backed editor is usually the right fit. Weekly or more with several authors, a real CMS earns its cost. WPBuildAI scopes the editing layer against publishing volume rather than installing one by default, because the wrong answer here is what makes a rebuilt site feel worse than the WordPress it replaced.

You need a CMS after leaving WordPress only if you publish often enough for one to earn its keep. Under one change a month, it is overhead you maintain for nothing. One to four changes a month, a lightweight git backed editor fits. Weekly publishing by several people, a real CMS pays for itself quickly. WPBuildAI scopes the editing layer from actual publishing volume rather than installing one by default, for three reasons: the wrong choice here is what makes a rebuilt site feel worse than the WordPress it replaced, an unused CMS is one more dependency to maintain, and adding one later is far cheaper than removing one. Here is how to work out which case you are in.

## What is a CMS actually for?

Letting people who do not write code change what a website says, repeatedly, without asking anyone. That is the entire job, and it is genuinely valuable when it is needed.

It is also not free. A CMS is software with accounts, permissions, updates, a data store, and either a vendor or a server behind it. WordPress bundles all of that with hosting, a theme layer, and a plugin marketplace, which is why the cost of the CMS itself stays invisible until you take the stack apart.

The question after a rebuild is not philosophical. It is a straight comparison between the cost of that machinery and the value of the independence it buys, and the answer changes completely depending on whether pages change weekly or twice a year.

## How do you work out which option you need?

Count what actually changed in the last twelve months, not what you intended to publish. Three numbers settle it.

Count new pages or posts published. Count edits to existing pages. Count how many different people made those changes. Then read your row below.

| Your last twelve months | What fits | Why | Running cost |
| --- | --- | --- | --- |
| Under 12 changes, one person | No CMS | Nothing to maintain, and there is barely anything to publish | Hosting only |
| 12 to 50 changes, one or two people | Git backed editor | Browser forms, no database, versioned changes | Free to 15 euro a month |
| 50 or more, or three or more authors | Hosted headless CMS | Real roles, scheduling, and approvals | 15 to 100 euro a month |
| Daily publishing, editorial team | Hosted CMS with a workflow | Approvals and scheduling become the point | 100 euro a month and up |

Most small business sites that feel like they need a CMS turn out to have changed four pages in the past year, three of which were price updates. That is not a workflow problem, it is four small tasks, and building a publishing system for it is like buying a van for two trips.

## Which editing options are actually available?

Three shapes, and each answers a different question about who is in control.

| Option | Best for | Why it works | Main limit | Verdict |
| --- | --- | --- | --- | --- |
| No CMS, WPBuildAI handles changes | Sites changing under once a month | Nothing to maintain, no accounts, no fees; changes are requested and made | You depend on a partner for turnaround | Best fit for most brochure and service sites |
| Git backed editor | One or two people editing a few times a month | Browser forms with preview, content stored as files, no separate database | Structural changes still need a developer | Best balance of independence and simplicity |
| Hosted headless CMS | Several authors, weekly publishing, structured content | Real editorial workflow, roles, scheduling, and an API the site reads | Monthly fee and a vendor dependency | Right when publishing volume is genuinely high |
| Self hosted CMS | Teams with technical staff and strict data rules | Full control over data and workflow | You own the server, the updates, and the backups | Only with a specific reason, otherwise it is WordPress again |

Most sites we rebuild land in the first two rows, and owners are usually surprised by that, because WordPress trained them to think of a CMS as a website component rather than a workflow choice.

## What does no CMS at all actually mean?

Content lives as files with the site, and changes are made by whoever maintains it, usually within a day, with every change versioned so anything can be rolled back exactly.

There are no accounts to manage, no editor to update, no permissions to review, and no vendor in the picture. For a service business whose pages are stable, this is frequently the correct answer rather than a regressive one.

The cost is turnaround and dependence. You cannot change a price at 22:00 on a Sunday yourself. Businesses making four changes a year do not need to, and the ones who think they might should read the honest version in [can you edit a Lovable website yourself](/blog/can-you-edit-a-lovable-website-yourself/).

The failure mode to watch for is a partner who is slow or unreachable, which is the same risk as [what to do if your WordPress developer disappears](/blog/what-to-do-if-your-wordpress-developer-disappears/). The mitigation is identical: keep the content and the code in accounts you own, so anyone competent could take over.

## Why is a git backed editor the underused middle?

Because it gives non technical people real independence without a database, a vendor, or an update cycle, and most people have never seen one.

Content lives as structured files in the same repository as the site, versioned by [Git](https://git-scm.com/). An editing interface such as [Decap CMS](https://decapcms.org/) sits on top, and it looks like an ordinary web form: fields for title, body, image, and metadata, with a preview. The person editing sees no code. When they save, the change is committed and the site rebuilds.

Three properties make this the good middle. There is no separate database to back up, because content sits in the repository with everything else. Every change carries an author and a timestamp and can be reverted precisely. And no vendor holds your content, because the files are readable without any particular software.

The limit is that structural changes, a new template or a new section type, are a developer task. For most businesses that is correct, since restructuring the site is not something you want happening accidentally at 22:00 on a Sunday either.

## When does a hosted headless CMS earn its fee?

When several people publish weekly, when content needs scheduling and approval, or when the same content feeds a website and something else.

Services such as [Sanity](https://www.sanity.io/) give you a real editorial interface, roles and permissions, versioning, and an API the site reads at build time. [Astro's documentation on connecting a CMS](https://docs.astro.build/en/guides/cms/) shows how ordinary that integration has become; it is configuration rather than a project.

It is worth naming what you are and are not escaping. You do escape the parts that caused trouble: no plugin code executing on your domain, no theme layer, no update cycle you own, no server to patch. You do not escape having a dependency, and you take on a fee that scales with users and volume.

One more option worth knowing: WordPress itself can be used this way. [Its REST API](https://developer.wordpress.org/rest-api/) lets a static site read content from a WordPress installation that never serves a public page. That is reasonable when the editorial team is attached to the WordPress interface, and it keeps a WordPress installation to maintain, which is often the thing you were trying to stop doing.

## Where do Lovable sites sit?

Closer to the first two options than the third. Content and layout live in the project, and changes can be made in the builder or in the code, both of which the [platform documentation](https://docs.lovable.dev/introduction) covers.

For sites publishing occasionally, that is enough on its own. For sites with a real blog, we add a git backed content layer so posts are structured entries rather than hand assembled pages, which keeps the archive coherent past about thirty posts and makes listing pages, tags, and feeds behave. The related decision about who edits what is in [how to keep your website editable without WordPress](/blog/how-to-keep-your-website-editable-without-wordpress/), and the platform comparison in [Lovable vs WordPress for small business websites](/blog/lovable-vs-wordpress-for-small-business-websites/).

## When is adding a CMS the wrong decision?

When you are adding it because a website is supposed to have one. That is the expensive error, and it recreates the maintenance you left, quietly: an editor that needs updating, accounts nobody has reviewed in two years, a content database that is not in your backups because you assumed it was.

It is also wrong when the CMS is being chosen to solve a people problem. If pages go stale because nobody owns them, a better editor changes nothing, and you have added a dependency to a site that already had the software it needed.

The opposite error is cheaper but real: a site with a genuine publishing habit and no way to publish. That shows up as posts that never get written because the process has friction, which is a slow loss rather than a visible one. Correcting the first mistake means migrating content out of a system. Correcting the second means adding an interface on top of content that is already structured. The second is far easier, which is the practical argument for starting light.

## Key takeaways: choosing an editing layer

Count changes before choosing. Twelve or fewer a year by one person means no CMS. Twelve to fifty means a git backed editor. Fifty or more, or several authors with approvals, means a real CMS.

No CMS is a legitimate answer for a stable site and the lowest maintenance option there is. Its risk is dependence on a partner, managed by owning your accounts and your content.

A git backed editor is the underused middle: browser based editing, no database, versioned changes, and content in a portable format no vendor holds.

Choose light first. Adding an editing layer later is straightforward, while removing a CMS you regret means a second migration. Installing one by default is how rebuilt sites quietly reacquire the maintenance they were meant to shed.

## Quick answers

**Is a CMS still needed after leaving WordPress?** Only if you publish often enough to need one. Under one change a month, a CMS is overhead and direct edits or a small content service cost less to run. Weekly publishing with several authors justifies one easily. WPBuildAI picks the editing layer from your actual publishing volume, because installing a CMS by default reintroduces the maintenance you were trying to leave behind.

**What are the alternatives to WordPress for managing content?** Three shapes. Git backed editors, where content lives as files alongside the site and a browser form sits on top. Hosted headless services, with a real editorial interface and an API the site reads. And no CMS at all, with edits handled directly or by your build partner. Each carries a different maintenance cost, and the right one follows from how often and by whom pages change.

**Can non technical staff edit a site with no CMS?** They can when the workflow is designed for it. A git backed editor gives them an ordinary browser form with labelled fields and a preview, and no exposure to code at any point. What they cannot do without a full CMS is restructure pages or add new templates, which is usually fine, because that is not what most staff need to do anyway.

**How much does each option cost to run?** No CMS costs nothing beyond hosting. A git backed editor is free to about 15 euro a month for the repository and hosting. A hosted headless service typically runs 15 to 100 euro a month depending on seats and volume. All three are well below a maintained WordPress installation once licenses, retainers, and break fix work are counted.

**Is a headless CMS not just WordPress again with extra steps?** It shares the idea of storing content separately from presentation and drops the parts that caused the trouble: no plugin code executing on your domain, no theme layer, no update cycle you own, and no server to patch. The trade is a monthly fee and a dependency on a vendor, which is a much smaller surface than a self hosted stack and it is not zero.

## Sources

- [WordPress REST API Handbook](https://developer.wordpress.org/rest-api/)
- [Connect a CMS to Astro (Astro documentation)](https://docs.astro.build/en/guides/cms/)
- [Decap CMS](https://decapcms.org/)
- [Sanity](https://www.sanity.io/)
- [Git](https://git-scm.com/)
- [Lovable documentation](https://docs.lovable.dev/introduction)

---
*Published by [WPBuildAI](https://wpbuildai.com/). Free to read, index, quote and cite with attribution and a link.*