What a small business actually needs from a CMS

There is a familiar shape to the six-month-old website. It launched well, the client was pleased, and nothing on it has changed since. The blog has one post, dated launch week. The team page still lists someone who left. The system is fully functional and nobody is using it.

This is nearly always a design failure rather than a client failure. The editing experience was specified around what the platform could do, instead of around the four or five things this particular business would genuinely need to change.

Model the content, not the page

The most damaging shortcut is handing over a single rich text field per page. It looks flexible and it is, which is the problem: it lets someone paste in text at the wrong size, break the spacing system, and gradually degrade a design they paid for, with no way to tell them they are doing it.

A proper content model asks what a thing is rather than how it looks. A project is a title, a client, a year, a summary, a set of images and some notes. A team member is a name, a role, a photograph and two sentences. Defined that way, the design stays intact regardless of what gets typed, and the person editing does not need to make a single visual decision.

• Every field should be answerable without judgement. If the label needs a paragraph of explanation, the model is wrong.
• Constrain what should be constrained. A category should be a fixed choice, not free text that will eventually contain three spellings of the same word.
• Make images behave. Fixed aspect ratios and automatic processing mean nobody has to think about cropping or file size.
• Require alternative text at the point of upload, where it takes ten seconds, rather than hoping for an audit later.

Only the fields that will actually change

Not everything needs to be editable. The homepage headline, which took two weeks to get right, does not need a text field that invites revision on a slow Tuesday. Making the entire site editable feels generous, but it produces an admin area so large that finding the one thing you came to change becomes work in itself.

The measure of a content system is not how much it lets you change. It is how quickly you can change the one thing you came to change.

The handover is part of the build

I write the editing guide as a short set of task pages, one per thing the client will realistically do, in the order they will do it. Add a project. Change the opening hours. Publish a post. No feature tours, no glossary, no explanation of the underlying architecture. If a task cannot be described in under a page, that is a signal to go back and simplify the model rather than to write more documentation.

Done properly, the result is a site that is still accurate a year later, which is a far better outcome than one that launched with an impressive amount of unused capability.