CMS and WordPress work without losing polish

The hardest part of CMS work isn't building the site — it's building a site that stays beautiful after a non-designer has edited it for six months. Every editable field is a small surface where the design can drift, and drift compounds: one off-brand button becomes a precedent, then a pattern, then the new normal.

I spent almost two years building and maintaining CMS sites — WordPress, custom PHP, proprietary platforms — for dozens of clients at once. At that scale you stop thinking about individual sites and start thinking about systems that survive their editors. These are the patterns that actually held up.

Constrain the editor, kindly

I give editors structured blocks with sensible limits instead of a free-form rich text canvas. A 'Team Member' block that accepts a photo, a name, a role, and a two-line bio cannot fall apart, no matter what gets typed into it. A blank WYSIWYG area absolutely can, and will, usually with a 14-point Comic Sans headline pasted in from Word.

The framing matters: constraints aren't about distrusting clients, they're a courtesy. An editor who can't break the layout edits with confidence. The best compliment CMS work gets is a client updating their own site for a year without a single 'the page looks weird now' email.

Bake the design system into the templates

The same design tokens that drive the marketing pages drive the CMS templates. Spacing, type scale, and colour come from one source — CSS custom properties or a shared stylesheet — so content added through the admin inherits the polish automatically rather than being styled by hand per page.

Concretely in WordPress terms: a tight theme.json or a locked-down block palette, template parts for anything that repeats, and absolutely no page-builder free-for-all on production pages. If a layout needs to be flexible, I build the flexibility as designed options — 'image left or right', 'two or three columns' — not as freedom.

Performance is part of the design

Client-editable sites accumulate weight: original-size photos uploaded from phones, a plugin per problem, embeds everywhere. I set the defences up front — automatic image resizing and WebP conversion, lazy loading below the fold, a hard rule that every plugin earns its place — because retrofitting speed onto a heavy site is miserable work.

This is also an SEO story. Editors care about ranking, and Core Web Vitals tie speed to visibility in a way clients understand. 'This plugin costs you half a second of load time' lands better than any technical argument about script bloat.

Hand over an owner's manual, not a mystery

Every handover includes a short, screenshot-heavy guide: how to add a page, how to update the team section, what the image size guidelines are, who to call when something looks wrong. Twenty minutes of documentation prevents months of support tickets — and prevents the well-meaning improvisation that erodes a design.

I also leave the admin itself tidy: unused plugins removed, menus labelled in the client's vocabulary rather than developer jargon, drafts and test pages deleted. The admin area is an interface too, and the care taken there tells the client how much care went into everything else.

Polish is a system property

None of these patterns are glamorous, and none of them show up in a portfolio screenshot. But polish on a CMS site was never about the launch-day state — any competent developer can make launch day look good. It's about month six, after real editors with real deadlines have done their worst.

Design the constraints, wire the tokens through the templates, automate the performance hygiene, and document the rest. That's how a client-editable site stays looking like the thing you shipped instead of a slow archaeological record of everyone who ever edited it.