Build it for the person who edits it

Every project has a moment that decides whether the site stays alive: the first time somebody on the client’s team wants to change a word and we are not in the room.

If that goes badly, the site quietly freezes. The team stops asking for small changes because small changes cost a support thread, and a year later the homepage still announces an event from last spring.

The handover test

Before we call a build finished, we send five changes to whoever will own the site and watch what happens. Swap the hero image. Rewrite the headline above the fold. Add a case study. Reorder the services. Change the phone number in the footer.

Nothing about that list is technical. All of it is the work a marketing team does in an ordinary week, and every one of the five goes wrong in a predictable way when the build was made for the developer rather than the editor.

Fields, not pages

The rule we hold to is boring: anything that repeats is a collection, and anything that appears once stays in the page.

• Repeats — case studies, posts, testimonials, services, client logos, social links. Each gets a schema, each gets an entry, each renders through one component.
• Appears once — the hero of the about page, the copy in a section that exists nowhere else. That lives in the page, where an editor can select it on the canvas and type.

The failure we see most in inherited projects is the middle ground: a “featured projects” section with three hard-coded cards, because at the time there were exactly three projects. Adding the fourth is a developer ticket. It should have been a row in a table.

A field the editor cannot see may as well be a constant. If they have to ask us to change it, we did not model it — we hid it.

Leave room for the copy they will actually write

A headline designed against six words of Latin will get fourteen words of English, and the ones that matter will be the last four. Layouts that only hold at the designed length are not finished; they are a screenshot.

We check every text field at roughly double its design length before handover, and again at half. Then we check what an empty optional field does. A section that collapses into a stray gap when a subtitle is left blank is a bug that reaches production through content, not code.

Media is a field too

The part that gets skipped: rich media usually arrives after launch. The article that needs a video. The case study that needs six screenshots instead of two. If the only way to add them is pasting an embed into a text box, the editor is writing HTML with no undo, and the result will not match the rest of the site.

So media gets modelled like everything else — an image picker for the cover, a small group of fields for a video, a repeatable list for an image strip. Adding a video to this post meant filling in three fields. It did not mean opening a code editor.

What good handover looks like

Twenty minutes. We open the CMS, walk through the collections, make one change together, and let them make the next one while we watch. Nobody takes notes, because there is nothing to memorise.

That is the whole test. If the walkthrough needs a document, the build is not done.