The bottleneck in most marketing teams isn't ideas or budget. It's that every idea has to pass through an engineering queue, where it sits behind product work that is, quite reasonably, more important.
A campaign that needed a landing page on Tuesday gets it three weeks later, by which point the campaign has moved on. Marketing learns not to ask. The site stops changing. Everything in the product operating model becomes impossible, because the mechanism to act doesn't exist.
The fix is architectural. Here's the setup that actually works, and the traps that make the well-intentioned version fail.
Why the obvious solution backfires
Give marketing a page builder with free-form blocks and you get autonomy immediately — and design entropy shortly after. Six months later there are fourteen button styles, five heading scales, pages that break on mobile, and a site nobody wants to show anyone. Engineering gets pulled back in to clean up, trust evaporates, and the builder gets locked down again.
Unconstrained freedom produces a site the brand team wants to redesign. The goal is freedom inside a system that can't produce a bad page.
The constraint is the feature. Marketing should be able to compose anything from the library and nothing outside it.
The four pieces
1. A component library that is genuinely finished
Not a design file — production components with every state handled: empty, long text, short text, missing image, mobile, dark, focus, loading. If a component breaks when someone writes a 90-character headline, it isn't finished, and it will break in public.
Keep the library small. Twelve components that compose well beat forty that overlap. Every component should answer a distinct layout question; if two answer the same one, delete one.
2. Content modelled as structure, not markup
The most common mistake is handing marketing a rich-text field and calling it a CMS. Rich text stores presentation decisions, and presentation decisions made in an editor are how design systems die.
Model content as fields with meaning: a hero has an eyebrow, a headline, a subhead, a primary action, an optional visual. Rendering is the component's job. This also means a design change updates every page at once, rather than requiring someone to edit two hundred of them.
3. Preview that tells the truth
Editors need to see the real page — real components, real breakpoints, real content — before publishing. Preview that approximates the result trains people to publish and check, which means mistakes land in production by default.
4. Performance budgets enforced in CI
The moment non-engineers can add images and embeds, weight accumulates. Set hard limits on bundle size and Core Web Vitals, and fail the build when they're exceeded. Not a dashboard someone reviews quarterly — a gate.
This one line of process is what keeps a fast site fast after eighteen months of edits, and it's the difference between the setup surviving and the site being rebuilt for speed reasons in two years.
The design rule
If a marketer can produce an off-brand or broken page using only the tools you gave them, the system is wrong, not the marketer. Constrain the components until bad output isn't reachable.
Governance that isn't bureaucracy
Autonomy still needs boundaries. Three that stay lightweight:
- Publishing rights by surface. Landing pages: publish freely. Homepage, pricing, navigation: needs a second pair of eyes. Match the review to the blast radius.
- Component requests go through design. When marketing needs something the library lacks, that's a design conversation, not a workaround. The workaround is how you get fourteen button styles.
- An owner for the system. One person responsible for the library staying coherent. Without it, entropy wins slowly.
What it takes to build
Realistically: the component library is 60–70% of the effort, and it's the part that gets underestimated because it looks like design work that's already done. Turning a design system into components that survive real content is where the engineering time goes.
The CMS configuration is comparatively quick. The preview environment and CI gates are a week or so. The part that takes longest and matters most is the fifty small decisions about what marketing can and cannot change — which is a product conversation, not a technical one.
We build this as standard in web engineering engagements, and we deliberately spend the first workshops on those boundaries rather than on tooling. Pick the tools after you know what the team needs to be able to do alone.
What changes afterwards
The measurable change is cycle time: a landing page goes from weeks to hours. The more valuable change is what becomes thinkable. Teams that can ship a page the same day start testing ideas they'd previously have dismissed as not worth the queue — and testing volume is what makes an experimentation program viable at all.
Engineering benefits too, and not just from fewer interruptions. When content stops being hardcoded, the codebase gets smaller and the deploys get less risky. Copy changes stop being releases.
Marketing stuck behind an engineering queue?
We build the component library, the content model, and the guardrails together — so your team ships pages in an afternoon without anyone worrying about what they'll break.
The short version
Give marketing composition, not construction. Finish the components properly, model content as structure rather than markup, make preview honest, and enforce performance in CI. The constraint is what makes the autonomy safe — and the autonomy is what makes everything else in your growth programme possible.
