A CMS that can’t break the design
Handing a designer the keys to his own site usually means handing him a way to wreck it. The fix wasn’t training. It was deciding what the editor is allowed to ask.
Aaron has published fifteen case studies on his studio’s site since June. I didn’t lay out any of them, and I haven’t had to fix one.
That isn’t because he’s careful, though he is. It’s because there’s nothing in his editing screen that can push a page out of spec. Every choice he makes, he makes from a short list I wrote with him, and the list is the design.
Serif + Gold is a brand and packaging studio. Aaron drew every page of the new site himself, and the old one was a Wix template where any edit could nudge a margin, swap a font, or round a corner he’d deliberately left sharp. Page builders give the owner control by giving them every control. The design survives exactly as long as nobody touches it.
The usual answer is a handover session. Here’s the editor, here’s what not to click, call me if it looks weird. That’s training someone to avoid a trap you left in the floor. It works until a busy Tuesday.
So I built the traps out instead. The rule for every field in his Studio was simple: ask for content, never for layout. Words, images, and a small number of named choices. Everything visual that follows from those choices lives in code, where only a deploy can change it.
Here’s what that looks like on a case-study section, the busiest screen he uses:
AARON CHOOSES THE CODE DECIDES
background: brand colour → which colour, per project
(volt for Goldy's, pine, flame…)
image shape: tall → 4:5 crop, sits two-up
fill "quote", not "body" → the block becomes a pull quote
kicker + heading + body → type scale, spacing, rulesHe never picks a hex value, a font size, or a width. He picks “brand colour”, and the site knows what brand colour means for that project. If he ever wants Goldy’s in a different green, that’s a design decision, and it gets made where the other design decisions live.
The field descriptions do the rest of the work a training session would have done. They’re written in his words, not the schema’s: “Leave blank for a quote block.” “Wide images run full width; tall and square ones sit two-up.” Instructions that sit next to the thing they describe don’t get forgotten between June and a busy Tuesday.
The best handover isn’t a lesson. It’s a form that can’t be filled in wrong.
Guardrails can go wrong in the other direction too. Lock too much and the client emails you for every change, which is the frozen site he was trying to escape. The test is whether the fence stops the mistakes or stops the work.
In July it briefly stopped the work. Aaron’s image sheet used three sizes, wide, tall, and square. The schema offered two. He had square photography with nowhere to put it.
The fix wasn’t to give him a width slider. It was to add a third option to the list, design what square looks like in code, and ship it that evening. The fence moved. It didn’t come down. That’s the pattern I’d defend to anyone: when a client hits a guardrail, the answer is usually a new choice, rarely a new control.
What this buys a design-led business is a site that stays the site. The hundredth case study renders with the same care as the first, because nobody laid either of them out by hand. And it buys the owner something harder to price. He can publish at eleven at night without wondering what he just broke.
If you’ve got a site you’ve quietly stopped editing because it might go wrong, that isn’t a you problem. It’s a form that’s asking you the wrong questions.
The full build, gallery morph and all, is on the work page.
Working on something like this? hey@samjennings.dev