Short answer: if your site is a marketing site under a few hundred pages, has a small number of editors, and you care about speed, security and being readable by AI assistants, a flat-file CMS is now a serious option. If you need e-commerce, memberships, many authors with workflows, or a plugin ecosystem your team already depends on, WordPress remains the right call. Most companies can decide in one meeting with the five questions at the end of this post.
What "flat-file" means
A flat-file CMS stores every page as a text file (Markdown with a block of settings at the top) instead of rows in a database. Grav is the one we build on. There is no MySQL, no wp_options table, no SQL injection surface. Backing up a site means copying a folder. Rolling back a change means git revert. The admin is a separate app that talks to the site through an API with per-user permissions.
That sounds like a developer’s preference, and it is, but the reason it matters to a marketing team is what it removes: database maintenance, most of the plugin-update churn, and a hosting bill sized for WordPress.
Where each one wins
| Your situation | WordPress | Flat-file (Grav) |
|---|---|---|
| Marketing site under ~200 pages | Fine | Fine, cheaper to run |
| Many authors, roles, editorial workflow | Strong | Simpler permissions |
| Marketo, HubSpot, 6sense, GTM embeds | Yes | Yes |
| E-commerce, memberships, LMS, events | Yes | No |
| Content reviewed in pull requests | With effort | Native |
| Every page readable as Markdown by AI | Needs a plugin | Built in |
| Database to secure and back up | Yes | None |
| Plugin ecosystem your team already knows | Huge | Small |
| Typical hosting | Managed WordPress tier | Small VPS |
The AI-readability point, specifically
AI assistants and answer engines read your site to decide whether to recommend you. They read visible text and structured data; they do not care about your CMS. But a flat-file site built the way we build them serves every page as clean Markdown at /page.md (try it on this site), exposes an MCP server so agents can read content with permissions, and ships llms.txt and structured data by default. On WordPress you can get most of this with the right plugins and a developer who sets them up; it just isn’t the default.
The editing experience is the real question
The objection we hear most is "our team can’t edit text files." They don’t have to. The visual builder we ship with flat-file sites lets editors click into a heading and type, reorder sections, swap images and add new sections from a library. It is closer to a modern block editor than to a code repository. The trade-off is that very large editorial operations, with dozens of contributors and scheduled publishing across roles, are still better served by WordPress.
Cost over three years
The build cost is similar either way; the work is in the design, content model and integrations, not the CMS. The difference shows up in year two and three: managed WordPress hosting, a security and update plan, and plugin licences versus a small server and a lighter care plan. For a 60-page company site, the flat-file total is usually meaningfully lower. For a site that leans on commercial plugins, WordPress’s ecosystem pays for itself.
Five questions that settle it
- Do you sell anything, gate anything with accounts, or run events through the site? Yes → WordPress.
- How many people publish each month, and do they need approval workflows? More than a handful with workflows → WordPress.
- Is there a plugin your team cannot live without? Yes → WordPress.
- Is the site mostly pages, a blog and a few forms? Yes → flat-file is on the table.
- Does leadership ask whether ChatGPT recommends you? Either works, but flat-file gets you there with less configuration.
If you answered "no" to the first three and "yes" to the fourth, ask for a flat-file quote next to the WordPress one. We will give you both and tell you which we would pick for your site. If you want a second opinion on an existing site first, the free audit covers platform fit.