Getting the developer out of the copy-change business.

The problem

Every headline, every price, every testimonial on the agency's own marketing sites was a code change. Someone in marketing wanted a word changed, so a developer opened a branch, and a two-second decision became a pull request. Multiply by several sites in two languages and the developer becomes a bottleneck on work that requires no engineering judgment whatsoever.

The obvious fix is a CMS. The non-obvious part is what a CMS does to your security surface. Most setups hand the consuming website an API token with read access to the content backend, which means every deployed front end is now holding a credential, and every credential is something to rotate, leak, or forget about.

And the usual second failure: editors can't see what they're doing. They change copy, publish, then load the live site to find out whether it looks right.

What I did

Built it as an internal Next.js platform consuming the agency's private design-system packages, so what an editor previews is rendered by the same components the real site uses.

• Slot-based content model. Pages are composed of named slots rather than free-form rich text. Editors fill slots; they can't accidentally restructure a page or break a layout, because the structure isn't theirs to edit.
• Preview-first editing. Six purpose-built editors, each rendering into the real component. You see the actual result before publishing, not an approximation in a textarea.
• A content API that ships no credentials. Content headed for a public web page isn't a secret, so the consuming site holds nothing worth stealing. Only the privileged operation, telling a site to drop its cache and re-fetch, is authenticated, and it verifies a signature rather than a shared token that would need rotating.
• An edit overlay on the live marketing site, so the path from spotting a typo to fixing it doesn't route through finding the right screen in a separate admin tool.
• Ships in lockstep with the marketing site, since both consume the same design-system packages.

The detail that mattered: separating the content from the action. The instinct is to protect everything, but protecting content that is by definition published means inventing a secret to guard a non-secret. Dropping that deleted a whole class of operational problem, and the protection moved to the one place real risk lives: the operation that makes a live site rebuild.

Outcome

• Live in production. The whole team edits all the marketing sites.
• I'm out of the copy-change loop entirely, which is the thing this was built to accomplish.
• No credentials deployed to any consuming front end, so nothing to rotate and nothing to leak.
• Editors publish having already seen the real rendered result.