What Marketer Autonomy Looks Like, Without Trade-offs For Developers
Key Takeaways
- Marketer autonomy no longer means technical debt when tools live in one platform.
- Old page builders, WYSIWYG editors, and plugins put marketer freedom outside the system.
- Developers own the content model and components. Marketers build pages from them.
- In Xperience by Kentico, forms, contacts, emails, and automation share one database.
- Example of autonomy in action: Racing Queensland cut development time 50% and raised feature output 150%.
It's Tuesday. The product launch is on Thursday. Marketing needs a campaign landing page. It has a registration form that feeds contact data, a gated whitepaper, a different hero for returning visitors, a three-step follow-up email sequence, and a pricing comparison that doesn't look like it was pasted from a spreadsheet.
The page itself is the easy part, but everything around it is difficult. The form lives in one tool, the emails in another, the contacts in a third. Someone has to connect them, test the sync, add tracking scripts to the template, and make sure the new table doesn't break on mobile.
That someone is a developer: one with a sprint full of other work and a codebase they'd rather not touch after hours on a Wednesday night. Marketing wants autonomy: the freedom to move fast without waiting in someone else's sprint. Development wants to protect the platform. Both are right.
I've seen versions of this conversation in more planning meetings than I can count. Most teams have accepted it as a law of nature: the more freedom you give marketers, the more you pay for it later.
But it isn't a law, it’s leftover from an older generation of tooling. Now, when it’s done right, independence for marketers no longer comes at the developer's expense. Let's look at why developers were right to be skeptical, what changed, and where the line between marketers and developers is today.
Why "marketer freedom" became a warning sign
Developers didn't become cautious of the phrase “marketing freedom” by accident. They learned it, from cleaning up afterwards.
Here’s what developers became wary of:
- Page builders that generated their own markup. Early drag-and-drop tools gave marketers freedom by letting them produce HTML: inline styles, nested wrappers, one-off layouts. Every page ended up with a different structure, and that ruled out structured content. When content is baked into layout, you can't reuse it on another channel or feed it to an app. You can't redesign the site without rebuilding pages one by one, either.
- WYSIWYG editors that fought the design system. Fonts pasted from Word, off-brand colors, tables that broke on mobile. The editor happily accepted all of it, unknowingly creating consistency issues.
- Plugins bolted on outside the architecture. WordPress made this pattern famous, but it's just as familiar on many other CMS platforms built around a plugin or package marketplace. Marketing needs a popup, a better form or an events calendar. Somewhere there's an extension for it, often free and sometimes maintained by a single community developer. A marketer might install it in an afternoon, or ask a developer to squeeze it into the next build. Either way, the immediate problem is solved, and under deadline pressure it may be the only quick way forward.
- The bill that arrives later. Every extension has its own release cycle and has to keep pace with each upgrade of the core platform. It also brings code from outside your team into your site. Some extensions get abandoned. Some end up in the next security advisory. Nobody sets out to own a dozen small third-party dependencies, but that's exactly what the team ends up with. When one of them breaks, it's the developer who has to fix it.
The lesson developers took from all this was correct at the time: marketer freedom meant technical debt. But if you look closer, you’ll see that the problem was never that marketers had freedom. It was where that freedom was located: outside the system, beyond anyone's rules.
What changed: freedom within the platform
The old trade-off came from fragmentation. Every extra tool was one more place where the developer's rules didn't apply, and one more integration to build, patch and keep an eye on.
One set of rules, applied everywhere
- Structured content: The development team defines the content model: content types, fields and relationships. Content types generate strongly typed code and are versioned in source control with the rest of the project. Content is created once and reused across the website, emails and headless channels.
- A component library developers own: Widgets, sections and page templates are built in code and registered in the platform. Marketers are able to work with what's in the library.
- A Page Builder that assembles rather than authors: Marketers compose pages from approved components. Developers decide which widgets and sections are allowed in each area of a page, so every spot has its own approved palette and the design system retains it.
- A rich text editor that respects the design system: Toolbars can be limited for each context, and the editor strips out HTML that isn't allowed.
- Governance built in, not bolted on: Roles, page-level permissions, content workspaces and approval workflows are part of the platform. They're configured once and apply to every editor.
Tools that work together from the beginning
Consolidation doesn't just protect the architecture. It also hands marketers a toolset that works from day one. In Xperience by Kentico, forms, contacts, activities, emails, automation, personalization and customer journeys share one database. There's no integration project to wait for before a campaign can start:
- Form fields built in Form Builder map straight to contacts.
- Each submission is logged as an activity that can trigger an automation process, which sends the follow-up email.
- The same contact data drives personalized widget variants on the landing page.
Go back to that Thursday launch. The registration form, contact data, follow-up emails and personalized hero are all in one platform, built from components that are developer-approved. After the developer sets up the building blocks once, the campaign belongs to the marketer.
For developers, fewer tools mean fewer integrations to build and maintain, fewer vendors to track and patch, and fewer potential vulnerabilities. For marketers, it means the tools are ready when the idea is.
Here's the whole argument: Marketers get autonomy. Developers get clean architecture. Everyone moves faster. This is made possible because the platform removed the complexity that made the trade-offs necessary in the first place.
Who owns what
| Developers define | Marketers do, on their own |
|---|---|
The content model: content types, fields, relationships | Create, update, compose and reuse content across channels |
Widgets, sections and page templates | Build and rearrange pages from them |
Rich text options for each context | Write and format within them |
Personalization condition types | Create personalized variants of widgets in web pages and emails |
Custom steps and triggers in marketing automation | Use them in their own automation processes |
Integrations with CRM, commerce and other external systems | Run campaigns on top of them |
Despite how it may sound, Industry 5.0 isn't a complete rejection of automation, nor is it nostalgia for the days of total manual work. Automation is still used for specific tasks and people complete tasks that require critical thinking, creativity, context, ethics and accountability.
Then there's the martech work that used to need a developer every single time:
| In a bolted-on stack | In one platform |
|---|---|
A developer connects the form tool to the contact database | Form fields map to contacts out of the box |
A developer keeps contacts in sync between the email tool and the website | Emails, contacts and the website share the same data |
A developer adds and maintains tracking scripts for each tool | Once tracking is set up, activities feed automation and customer journeys natively |
Permissions and workflow steps are usually configured by administrators or channel owners, not in code. Once they're set up, they apply to every editor, and to every AI-assisted action too.
"What I like best about Kentico is the flexibility it gives back to the user. It is a robust platform that allows me to make updates and add content in real time. I don’t have to send an email to my web developer and wait for my request to get into their production schedule. I have all the tools at my fingertips to edit my website so that it becomes more than just the digital nametag for our company; it is transformed into a trusted resource for all our visitors."
What developers get back
Marketer autonomy often gets pitched as a loss for developers. Customers tell us the opposite: their development and IT teams handle far fewer tickets and can now spend the time on innovative work. Here’s what we’ve seen:
- Fewer trivial tickets: No more "can you swap this image", "can you add a form field" or "can you publish this by 5 pm." These requests don't disappear, but instead they move to the people who own them.
- More real engineering: Time goes into the component library, integrations, performance and the content model: work that compounds instead of work that repeats.
- A cleaner codebase over time: Marketer changes happen through components, so there's nothing to clean up afterwards.
- Design decisions that shape the marketer's experience: A focused, well-designed component library is what makes marketers fast. Kentico's developer guides recommend combining focused widgets, sections and page templates instead of packing every option into a single component.
Racing Queensland is a good example of the positive outcomes of establishing marketing autonomy. After rebuilding on Xperience by Kentico with their partner Zeroseven, their editors gained more control over content updates through the Page Builder and templates, which reduced their reliance on developers. The team saw a 50% reduction in development time and a 150% increase in feature output for the same time and cost.
AI development tooling stretches the freed-up time even further. KentiCopilot brings Kentico-specific MCP servers, and AI agent skills into the IDEs developers already use: Visual Studio, VS Code, Cursor, Claude Code and GitHub Copilot. That means widgets and content types follow best practices from the first line. Less boilerplate, more craft.
The same principle holds on the marketing side. AIRA works within the same permissions and approval flow. Agents propose, and marketers review, approve and launch. In this process, AI amplifies expertise, not replace it.
Where the line is, and where it should stay
Autonomy doesn't mean developers are out of the picture. Some work belongs with them, and pretending otherwise is how the old problems come back:
- Integrations with CRM, ERP, commerce, search and other external systems
- New components: anything the library doesn't cover yet
- Data model changes: new content types, fields and relationships
- Advanced workflow automation, such as automated accessibility checks or hooks into external review systems
None of this limits marketer autonomy, but rather it's what makes that autonomy safe. Component restrictions guide editors toward the right choices, while roles, permissions and workflow decide who can publish what. The boundary is a design decision, not a bottleneck.
Not a truce, a better setup.
Developers build for marketers and marketers craft experiences for customers. Both get to focus on what they do best.
Autonomy won’t lead to marketers replacing developers, and it isn't AI replacing marketers, either. It's removing the dependency bottleneck, while people keep the judgment, the creativity and the final say. Consolidation is the architecture. Autonomy is the outcome.
Frequently Asked Questions
Roles, page permissions and workflow steps, which are configured once by administrators. The system checks all of them together before anyone can edit or publish an item.
Not for each campaign. In Xperience by Kentico, forms, contacts, emails and automation share the same data. Developers set up the building blocks once, and marketers run campaigns on top of them.
For marketers, yes. They build and edit pages without writing a line of code. Behind the scenes, developers build the widgets, sections and page templates in code, which keeps the output clean and consistent with the design system.
Integrations with external systems, new components, changes to the content model, custom steps and triggers in marketing automation, and advanced workflow automation. That's work that shapes the platform, not day-to-day campaign execution.
Agencies can deliver the content model and component library once and let the client's marketing team run with it. Less of their time goes into small change requests, and more goes into work that moves the client forward: new components, integrations and optimization.
It reinforces it. AIRA works within the same permissions and asks for approval before acting, while KentiCopilot helps developers build the components faster.
Get ready for your upgrade
Upgrading from Kentico Xperience 13 to Xperience by Kentico gives your marketing and development teams a unified and future-proof platform with native AI that reduces complexity, and helps you create more impactful customer experiences.
