Simple CMS: Why Small Beats Big for Most Websites

Last spring I took over a brochure site for a small law firm. Five pages, a contact form, a map. It ran WordPress with 23 plugins, a page builder nobody remembered installing, and a database holding nine years of spam comments. The site did less than a stack of HTML files would have done, yet it needed monthly updates, a security plugin, a caching plugin, and a backup plugin to keep the caching plugin company. That job is why I now hand every client the same rule: use the smallest tool that does the job. For most sites, that tool is a simple CMS.

This piece covers what a simple CMS actually is, the maintenance costs the big systems never put on the invoice, and how to tell which side of the line your site sits on.

What a simple CMS actually is

Strip the term down and a CMS does three things: it stores your content, it lets you edit that content without an FTP client, and it renders pages for visitors. A simple CMS does those three things with as few moving parts as possible, usually no MySQL server, no plugin marketplace, no theme framework with its own release cycle.

• Flat-file CMSs like Grav, Bludit, or Pico store content as Markdown or JSON files in folders. The site is the file tree.
• Single-file CMSs like WonderCMS or the Restorix CMS squeeze the whole admin panel into one PHP file that sits next to your content.
• Static site generators go one step further: no live admin at all, just HTML rebuilt on every change. Great, until a client wants to fix a typo at 9 pm.

What you give up is user accounts, editorial workflows, comments, and a plugin for every occasion. What you get back is a site small enough to hold in your head.

The maintenance bill nobody mentions

WordPress itself is not the villain. The burden comes from everything orbiting it. Core wants updates. The theme wants updates. Each of your 15 to 40 plugins wants updates on its own schedule, written by different people, tested against different versions. Every update is a small lottery ticket: usually fine, occasionally a white screen on a Saturday.

Here is the arithmetic I walk clients through. A typical small WordPress site needs:

• Update checks and application: 30 to 60 minutes a month, more on the months something breaks.
• Backups you have actually tested: another 30 minutes, and you should be test-restoring quarterly.
• Database hygiene: revisions, transients, spam, orphaned metadata. Skip it and a 50-page site drags a 400 MB database behind it.
• Security watching: when a popular plugin discloses a vulnerability, your patch clock starts. Incident-response reports from firms like Sucuri routinely trace a large share of CMS infections back to outdated plugins and themes.

A flat-file site inverts most of that list. No database to clean or inject. The attack surface shrinks to one admin file and your PHP version. Backups become a cron job that rsyncs a folder. I have flat-file sites that ran three years between logins and survived a server move with zero drama.

Flat-file vs database: what changes day to day

Notice none of this is about benchmark charts. A cached WordPress site and a flat-file site both serve pages fast. The difference shows up in month ten, when the simple site still needs nothing and the big one needs its monthly hour of attention.

Single-file CMSs: the extreme end of simple

The most radical version of the idea is the single-file CMS: the entire admin, editing, saving, file management, inside one PHP file. WonderCMS built its whole identity on this, shipping an admin as a lone index.php. We took the same route with the Restorix CMS: one file at /webarchive-cms.php, added to every restored site we deploy, with content editing, site-wide search & replace, and a file manager inside.

Why would anyone compress a CMS into a single file? Three practical reasons:

1. Zero install. No wizard, no database credentials, no version matrix. Upload the file, open it, edit.
2. Zero footprint. Delete the file and the site is plain HTML again. Nothing hides in a database you forgot to export.
3. Hard to break. The Restorix CMS ships with safe mode on by default, and each deployed site gets its own randomly generated admin password, shown in your dashboard. Small surface, small blast radius.

A one-file admin will never run an online magazine, and it is not meant to. It exists so a 40-page company site can be edited twice a year without hiring someone to remember how the admin works.

Where a simple CMS falls short

I would rather lose a deal than sell the wrong tool, so here is the honest list. Skip the simple CMS when:

• You sell things. Real catalog, cart, taxes, invoices, WooCommerce or a dedicated shop platform earns its complexity. A client's store with 800 SKUs is not a flat-file candidate.
• Many hands touch content. Editorial roles, approval flows, per-user permissions. Simple systems usually assume one admin.
• Content is relational. Events linked to venues linked to cities, faceted filtering across five taxonomies. That is a database's home turf.
• You need accounts, forums, or comments. A 2009 phpBB forum with 60,000 posts stays on a database. Period.
• The team already knows a big CMS. Retraining sometimes costs more than maintenance. Boring, but true.

Rule of thumb: if strangers must log in and do things on your site, you need a database. If the public only reads, you probably don't.

A quick decision checklist

Answer these five questions before picking anything:

1. How many pages will this have in two years? Under roughly 500 reads fine as flat files.
2. Who edits it, and how often? Monthly edits by one person favor simple tooling.
3. Does the public interact, accounts, carts, comments? Any yes pushes you toward a database.
4. Who maintains it after launch? If the honest answer is 'nobody, really', simplicity is a feature, not a compromise.
5. What happens if it gets hacked or the host dies? With a simple CMS the honest answer is 're-upload the folder'.

Score four or five toward 'small and read-only' and a simple CMS will save you real money over three years, mostly in hours you never spend.

How to try a simple CMS on a real site

You don't need a greenfield project to test the idea. Two low-risk routes:

First, rebuild a small existing site. Take that five-page brochure site, copy the text out, and rebuild it on Grav or Bludit under a subdomain. A weekend covers it, learning curve included. If the client edits it without calling you, the experiment passed.

Second, the route people forget, restore an old site you already lost. If a site died with an expired domain or a lapsed hosting plan, its pages are usually still sitting in the Wayback Machine. Run it through a free estimate: Restorix counts the archived files and locks the price before you pay, then deploys the restore to your hosting with its single-file CMS already in place. What you get back is not a frozen museum copy but a small editable site, which is exactly the niche a simple CMS fills. If anything fails, the refund hits your balance automatically.

Either way, the test costs days, not months. That is the whole point of simple.