Content in version control

A content management system moves editing closer to the person who wants to edit. That is a genuine benefit and it should be stated plainly before the argument against it. Someone in the business can fix a typo at nine at night without filing a ticket, and for a site whose content changes weekly that convenience compounds.

What it costs is verifiability. Once copy lives in a database behind an editor, the text on the page is no longer part of the thing that gets built. Nothing can inspect it at build time, because at build time it does not exist yet. A false certification, an expired disclosure, a service the business stopped offering two years ago, a price that changed in January — each of these can enter the site through the editor and stay there indefinitely, and the only mechanism standing against them is somebody noticing.

Here, copy lives in the same place as the rest of the site, under version control. That single decision is what makes the rest of the standard possible. Because every rendered sentence is a value in a file, an automatic check can extract all of them and run rules across the set: pattern matches for claims that require a paired disclosure, spelling and locale checks, placeholder markers that should never reach production, phrasing that asserts something the business cannot substantiate.

The mechanism generalizes past text. Where a claim carries a legal condition, the claim and its disclosure are modeled as one object, so a component cannot render the claim without rendering the condition. Where a value must never be invented, the type carries no field for it at all — an identifier component with no value property cannot display a fabricated license number, because there is nowhere to put one. These are not policies anyone has to remember. They are properties of the code.

The cost is real and worth stating without softening it: a copy change goes through us and through the checks. There is no editing screen, and somebody outside the process cannot change a word on the site without somebody who is inside it. For a business that publishes daily, that is the wrong trade and we will say so. For a business whose site is a standing description of what it does and what it is licensed to do — which is most businesses — the change is live the same day and buys a guarantee that nothing on the page contradicts what was verified.

There is a second-order benefit that tends to matter more than expected. Because copy is in version control, every change to what the business claims has an author, a timestamp, and a diff. When a question arises about when a page started saying something, the answer is a command, not an investigation. On sites where claims carry regulatory weight, that history is the difference between being able to demonstrate a practice and being able to assert one.

The approach also removes an entire category of operational risk. A content management system is software that runs in production, holds a database, exposes an authenticated admin surface, and requires patching. Sites built this way have no database, no admin login, no plugin ecosystem, and no upgrade path that can break the front end. What is published is fixed output. The attack surface that comes standard with a CMS is not defended here; it is absent.

Where a genuine editing workflow is needed — a business that publishes frequently, or a team where several people write — we build toward it deliberately instead of adopting a CMS by default, and the choice is made in the build specification, not discovered halfway through. The question is not whether editing convenience matters. It is whether this particular site's content changes often enough to be worth the verification it gives up.

In practice the editing burden is smaller than it sounds, because most requested changes are not prose. They are a phone number, a set of hours, a service added or retired, a price band. Each of those lives in a single named field in a configuration file, and changing it is a one-line edit that a non-technical person can request in a sentence and see live the same day. The cases that genuinely require an editor are long-form pieces published on a cadence, and a site with no blog does not have them.

The arrangement also changes what a handover looks like. When an engagement ends, the client receives everything: every word on their site, its full revision history, and the checks that enforce it — not credentials to an administrative panel whose contents exist only inside a running database. What transfers is the artifact rather than access to a system, and it remains buildable by anyone who can run the toolchain.

None of this is an argument that content management systems are badly built. It is an argument about where the text lives relative to the thing that checks it. A CMS puts the copy outside the build; this approach puts it inside. Every consequence above follows from that one placement decision, and it is worth making deliberately instead of inheriting from whatever the last vendor set up.