What breaks when marketing gets edit access

The same complaints come up on most sites we take over. A headline drawn for 6 words is carrying 19 and wrapping into the image beneath it, and a card grid sets 3 lines of text beside 11. The hero slot was drawn at 16:9, and somebody uploaded a phone photo, 3:4, portrait, several megabytes straight from the camera. With object-fit: cover the crop takes the subject's head off; left to its intrinsic height the image pushes the call to action below the fold. Both outcomes are the page doing exactly what it was told to do.

Accessibility goes last and quietest. The toolbar offers H1 through H6, so the page has several H1s and skips levels on the way down, and alt text was optional, so it is empty across the library. Nobody did any of this on purpose, and all of it was available.

Every failure above is a field that accepted a value the design cannot render. A text input with no maximum length tells the person using it that any string is fine here. An endpoint that accepts an unbounded string and then blames the caller is a bug, not a user error, and a CMS is that endpoint with a nicer form around it. The editor is authenticated and on your side, which changes nothing, because trust does not make a value renderable.

The editor cannot see the constraint either. The design exists as a set of CSS rules and a file they have never opened. Nothing in the admin panel says the headline was drawn to 2 lines at 375px, or that the card grid assumes equal text lengths. Asking a marketing team to hold that in their heads, across staff changes, is asking them to be the type system.

A written style guide does not fix it. Rules on a PDF are enforced by memory and goodwill, and both run out at 6pm on a Friday when somebody is pasting in a press release handed to them 10 minutes ago.

Derive the limits from the design itself, and mind how you measure. A character count is a weak proxy for rendered width: the same count buys a narrow run of i and l, or a line of capital Ws. Render the string in the real webfont at the real size, with canvas measureText or an offscreen node, and validate the width the headline will occupy at your narrowest breakpoint.

Cap the input at that bound and show the counter as they type, so the limit is visible while the sentence can still be shortened. A warning after the save is memory and goodwill again, dressed as a guardrail. The rest follows the same logic, field by field: a separate field for each thing, never a single rich text field holding a whole page.

• A rich text editor exposing only the marks you style, the rest stripped on save so the record matches the page.
• Images derived on upload: server-side crop to the declared ratio, a focal point control, generated sizes so the original never ships.
• Alt text required, with a decorative checkbox beside it, because a requirement with no exit gets defeated by a space.
• No raw HTML field. An embed takes a URL, matched against providers you have already styled and budgeted for.

Preview is the last piece, and the hardest. A pane that renders desktop only passes content that breaks at 375px, and a pane that approximates the template drifts from production. What holds is a draft route rendering the real components from the unsaved values, embedded as an iframe the editor can resize to the breakpoints you support. It cannot diverge from the live page, because it is the live page reading different values.

The objection to this is not the build time. It is that a tightly bounded CMS has its own failure mode, familiar to anybody who has locked a site down. Marketing wants a page the template does not have, so they raise a ticket and wait, and the site slowly stops changing. Or they stop asking, put the campaign into a builder on a subdomain, and now there are 2 sites, 2 design systems and 2 sets of analytics.

So the flexibility gets designed rather than left over. Give the editor a small, fixed set of block types to order and repeat freely, each bounded on its own terms, so a new page is an arrangement rather than a request. Then name the route for the block that does not exist yet: who builds it, and how long it takes. Most of the resentment aimed at locked-down systems is aimed at having nowhere to go when the bounds are wrong.

Limits derived from a design couple the content model to that design, and the bill arrives at the redesign: content legal under the old bounds violates the new ones. Bound generously enough that the template can move, keep each limit in a single place the CSS and the schema both read, and treat content that breaks a new limit as a planned migration rather than a surprise. The coupling is worth choosing, and it is not free.

There is a test for this, and on a small site it costs an afternoon. Fill every field with the worst content the CMS will accept: the longest headline the limit allows, the tallest image in the widest slot, every optional field empty, a list with 1 item and the same list with 12, an unbroken word long enough to overflow. Then look at the result at 375px and at 1440px.

Run once before handover, that afternoon expires. As soon as somebody raises a max length or reworks the card grid, the page you checked describes a schema that no longer exists. So the worst content belongs in the repository as seed data, rendered at a route in every environment and checked whenever the schema or the template changes, snapshot-tested where you have the harness.

The page is not a hypothetical. Your CMS is promising right now that it can produce it, and given enough months somebody will. If the design holds under that content, the marketing team cannot break the site, because you already did.