Every studio has seen this and most of us have caused it. The site launches, everyone is pleased, and then it sets like concrete. Small changes queue up behind a developer who has moved on to other clients. Eventually the marketing lead gives up and starts putting the real, current information on LinkedIn instead, which is where their audience now finds out what the company actually does.
The usual diagnosis is that the client did not maintain their site. The more useful diagnosis is that somebody handed them a thing they could not maintain.
The CMS decision is a staffing decision
Choosing how a site is built looks like a technical question and behaves like an organisational one. The only question that matters is: who is going to change the words on this page in March, and what will be open on their screen when they do it?
Answer that honestly and the choice mostly makes itself. If the answer is a founder between two meetings, they need a visual editor and a page that cannot break. If the answer is a marketing team of four shipping campaign pages every month, they need a proper content model and predictable components. If the answer is an in-house engineer, you have more freedom than you think and should probably use less of it.
What does not work is choosing the stack for the launch and discovering the staffing answer afterwards. The launch is one week. The other question is every week after that.
A site nobody can update is a brochure with hosting costs.
Fields, not blobs
The most common failure inside an otherwise decent CMS is the single rich-text field. One big editor per page, everything typed into it, formatting applied by hand. It feels flexible on day one and it is a slow disaster: every new page drifts a little further from the design, headings get faked with bold text, and after a year nobody can restyle anything because the styling is scattered across two hundred inline decisions.
The alternative takes an extra afternoon during the build. Break the page into named fields — eyebrow, headline, standfirst, body, proof — and let the design own how each one looks. The editor's job becomes writing, not formatting. Nobody can accidentally set a heading in 19px grey.
The test for a content model is whether it can be filled in badly. Give it a headline three times longer than the one you designed with. Leave the optional image out. Put in a client name with an ampersand and a case-sensitive lowercase first letter. If any of those break the layout, the model is not finished, and the person who will discover this is not you.
What the visual builders are actually good at
Framer and Webflow take a lot of criticism from developers and most of it misses the point. Yes, you give up some control. In exchange, the person who owns the site can change it on a Tuesday afternoon without a deployment, and that is frequently worth more to a business than the last five percent of implementation elegance.
We reach for them when the site is mostly marketing surface, when the client has no engineer, and when the shape of the content is going to keep changing for a year. We build custom when there is real interaction to design, when the site has to talk to systems that already exist, or when performance is the product and every kilobyte needs arguing over.
The mistake in both directions is the same: picking based on what the studio enjoys building rather than what the client will be able to run.
Design for the content you will actually get
Layouts that only work with perfect content are a hidden liability. The card grid looks immaculate with three items and collapses at four. The team section assumes everyone has a headshot on the same grey background. The testimonial block needs exactly two lines of quote.
Real content is lumpy. So the components have to be specified with their awkward states designed, not discovered:
- Empty. What does this section look like with nothing in it — and can it be switched off entirely without leaving a gap?
- Overflowing. The longest plausible string, not the one from the mockup.
- Missing media. A sensible fallback that is designed, rather than a broken image icon.
- Odd counts. A three-column grid with five things in it.
This is unglamorous work and it is most of what separates a site that ages well from one that looks neglected within a year.
The handover is a deliverable
Handover is usually treated as an email with logins in it. It should be a designed part of the project, because it is the moment the site stops being ours and becomes theirs.
What we think it should include: a short screen recording per content type, showing the actual edits somebody will need to make — change a headline, add a project, swap a photograph. A one-page document naming every component in the same words the editor sees in their interface. A note on what deliberately cannot be changed, and why. And one live edit made together on a call, by them, not by us, so we find out on that call whether the thing is genuinely usable.
The first Tuesday test
Before launch, ask the person who will own the site to make one real change in front of you. Not a rehearsed one. Something they actually want on the page.
If they get through it without asking you a question, you have built something that will still be true about the company in a year. If they can't find the field, the site has a shelf life, and everyone involved is about to pretend not to know that.
We hand over sites with a walkthrough and a written map of every editable field, so that needing us again is a choice. Start a project if that is the kind of thing you want to own.