Design CMS workflows, reusable blocks, and approval controls so marketing teams publish landing pages faster and safer.
Get concise advice on choosing the right CMS, understanding migration costs, and avoiding expensive implementation mistakes before they become roadmap problems.
No spam. Unsubscribe anytime.
If every landing page requires a developer, the CMS is not doing its job.
That is not a criticism of developers. It is a diagnosis of the system around them.
I have seen this pattern across enough client projects to know it is not a people problem. Marketing is not being unreasonable. Developers are not being obstructionist. The bottleneck exists because the website was never designed to support the way marketing actually needs to operate.
A single landing page request does not look like a crisis.
Marketing needs a campaign page. Copy is written. Images are prepared. A ticket is opened. A developer assembles the layout. Review happens. The headline changes. The CTA changes. The form needs one more field. The page ships.
Fine. Manageable.
But multiply that by product launches, seasonal campaigns, paid ad variants, partner pages, event registrations, and vertical-specific sales pages, and the shape of the problem changes.
The company no longer has a website bottleneck. It has a publishing workflow problem.
Developers get pulled away from meaningful engineering work to swap copy and duplicate sections. Marketing feels chronically blocked. Leadership sees slow campaign execution but struggles to name the root cause.
This is also why so many website rebuilds disappoint. The frontend gets redesigned, the visuals improve, the new site launches — and six months later the same bottleneck is back. The website looks better, but the operating model behind it never changed.
A rebuild that does not address the publishing workflow is mostly cosmetic.
The frustration often gets directed at developers, and that is usually unfair.
Developers are asked to do repetitive assembly work because the system does not give anyone else a safe way to do it. If the CMS has no guardrails, no reusable sections, no permissions model, no preview — then yes, you need a developer every time. Not because the work is technically difficult, but because the CMS cannot be trusted to protect the website without one.
A developer's best contribution to a publishing workflow is not manually rebuilding the same page structure on a tight deadline. It is building the foundation that lets the organization move without them for routine work.
That foundation includes reusable page sections, controlled layout options, design-safe defaults, preview before publish, role-based permissions, version history, approval states, SEO field requirements, and analytics defaults baked in.
When those pieces exist, the developer's involvement shifts from production work to system work. That is a much better use of the role.
The common overcorrection is to give marketers a visual builder where almost anything can be changed.
This feels like the solution. Then the side effects arrive.
Pages drift from the design system. Spacing becomes inconsistent. Mobile layouts break quietly. SEO fields get skipped. Forms behave differently page to page. Someone duplicates a landing page that already had broken analytics. Someone copies old compliance text verbatim.
The publishing bottleneck is gone. Governance debt takes its place.
The right answer is not maximum freedom. It is controlled flexibility.
Marketers need enough range to move quickly on routine pages, but not so much range that every page becomes an unofficial design experiment. The CMS should feel like a trusted menu, not a blank canvas.
A well-designed CMS does not ask marketers to design from scratch. It gives them a library of reusable sections — hero, feature overview, testimonials, comparison table, FAQ, CTA, form, case study callout — each with defined options for copy, images, background variants, and layout choices within safe boundaries.
The marketer assembles the page. The system protects the brand, the structure, and the workflow. The developer never needs to be involved for that specific task again.
In Payload CMS, block-based content models make this natural. Editors get flexible page assembly without unrestricted control. But the principle is not Payload-specific. WordPress has reusable patterns. Webflow has components and collections. Sanity, Storyblok, and Contentful all have versions of this model.
The pattern is always the same: developers define the building blocks, marketers assemble pages from those blocks, the system holds the guardrails.
Companies often frame developer dependency as a resource cost. How many hours does it take to build a landing page?
That is the wrong calculation.
The real cost is campaign velocity.
When marketing waits on development capacity, the delay is not just one page. It is the experiment that did not run. The offer that was not tested. The regional campaign that launched late. The ad group that had no matching page. The sales team that had to send prospects to the homepage because a vertical page never got built.
A few days per page compounds into quarters of slower learning and more cautious decision-making. Teams that have to fight for every page start requesting fewer pages. Fewer experiments means the company learns slower and adapts later.
Publishing workflow is a business performance issue wearing the costume of a CMS problem.
Not every marketer needs the same level of access.
A junior marketer might draft but not publish. A marketing lead might publish campaign pages but not touch global navigation. A regional team might localize approved content but not create new layouts. Legal might need review rights. Developers keep ownership of schema and integrations.
That structure is not bureaucracy. It is how you make flexibility safe.
Without it, companies choose between two bad options: lock everything down (bottleneck) or open everything up (chaos). The right system is more specific. People change what they are responsible for. The system protects everything else.
The same logic applies to approval workflows. When a company publishes one page per quarter, a Slack message is fine. When it publishes every week, informal review breaks down. Versions blur. People approve drafts that then get updated. Someone publishes the wrong iteration.
A proper approval workflow makes page status visible and unambiguous: draft, in review, approved, scheduled, published, archived. That sounds simple. It changes how teams actually work.
None of this means removing developers from the website.
There are clear cases where they should be deeply involved: custom interactivity, complex form logic or routing, integrations with pricing or accounts or inventory, personalization, performance-critical pages, new compliance requirements, new section types being added to the system.
The goal is to stop using developers for repeatable content assembly, not to eliminate them from the publishing process.
A healthy workflow separates routine publishing from new system work. Every repeated page request is a signal. If the same type of page keeps being asked for, it should become part of the system. That is how the CMS improves over time and how the developer's leverage grows rather than gets consumed.
Most CMS evaluations compare features. Does it have localization? Roles? Preview? Scheduled publishing?
Those questions matter but they come second.
The better starting point is the publishing workflow itself.
Who creates landing pages? Who writes and approves copy? Who checks SEO? Who owns analytics? Who can publish? Who can roll back? Which sections should be reusable? Which pages genuinely require development?
Once those questions are answered, the CMS requirements become much clearer, and the gap between what the current system provides and what the business actually needs becomes harder to ignore.
The strongest CMS for a marketing team is often not the most flexible one. It is the one with the best constraints — constraints that reduce decisions, protect quality, and let the team move without starting a ticket every time.
If every landing page still needs a developer, the issue is probably not the developers. It is that the CMS, design system, and publishing workflow were never designed as a single coherent system.
That is worth fixing before rebuilding the next page.
Thanks, Matija