Your engineering team can build a new marketing page in a few hours.
But getting it live takes weeks.
Not because anyone is slow. Not because the work is hard. But because the system wasn’t built for this kind of change.
AI has made this tension more visible.
With the right tools, small, highly technical teams can generate pages directly in code, iterate quickly, and bypass much of the infrastructure that used to feel required. For teams where the same people design, write, build, and ship, working without a CMS can be a rational choice1.
That approach can work well.
But it optimizes for a very specific shape of organization. And most teams don’t look like that for long.
For most teams, a marketing website isn’t just a set of pages. It’s a marketing platform. And treating it like one fundamentally changes the cost of change.
A marketing site has an audience and users, and they are not the same
This is where the complexity usually gets underestimated.
A marketing website’s audience is prospects, customers, and the public. But its users are internal: editors, marketers, designers, SEO specialists, data teams, legal, brand, leadership.
Those two groups have very different needs. And the platform has to support both at the same time.
Once you separate those layers, the work stops being about pages and starts being about leverage.
The questions shift to:
- How long does it take marketing to launch an experiment without engineering?
- How safely can teams make changes without risking brand, performance, or compliance?
- How easily can content be reused, measured, and evolved?
- How expensive is each change in engineering time, context switching, and opportunity cost?
These are not theoretical concerns. They show up as cycle time, missed experiments, delayed campaigns, and teams waiting on each other.
AI changes how we build, not what breaks at scale
AI is an accelerant.
It lowers the cost of implementation. It helps teams generate code faster. It makes iteration feel cheap. And that’s powerful.
What AI doesn’t change is organizational complexity.
It doesn’t decide who can publish what. It doesn’t design workflows. It doesn’t resolve governance, analytics consistency, accessibility requirements, or long-term maintainability.
In fact, AI often makes bad architecture ship faster.
When structure is missing, speed just moves the bottleneck elsewhere. Marketing waits on engineering. Engineering becomes the gatekeeper for small changes. Experiments that could have shipped in a day take weeks instead.
A CMS isn’t just a content store. It’s where decisions get made explicit rather than implicit. About:
- how content is modelled and reused
- how editorial workflows function
- how accessibility and localization are handled
- how performance and analytics are enforced
- how new page types and experiments are introduced
Choosing not to have that structure is still a choice. But it pushes those decisions into code, documentation, or a handful of people. That can work at small scale. It becomes fragile as velocity and headcount grow.
Hard-coding pages feels fast, until it becomes expensive
Hard-coding pages often looks like speed.
And initially, it is.
But over time, the costs are predictable. Marketing requests pile up. Engineers spend more time on one-off changes. Experiments slow down because every iteration requires a deploy. Eventually, teams start talking about a rebuild.
The real cost isn’t just time. It’s lost opportunity.
When a team could test three variations in a week but only ships one in a month, learning slows. When campaigns miss windows because changes are gated on engineering availability, revenue is left on the table.
None of this happens because teams made bad decisions. It happens because the system was optimized for immediacy rather than adaptability.
“We’re not most companies” (and when that’s true)
A common reaction here is: This doesn’t apply to us. We’re technical. We move fast.
Sometimes, that’s true.
If your marketing site is owned end-to-end by a small engineering team, if content changes are infrequent, and if marketing doesn’t need autonomy, a code-first approach can be efficient.
The question is not whether it works today. It’s how long it keeps working.
As soon as marketing needs to move independently, as soon as experiments increase, as soon as more people need to touch the system, the shape of the problem changes.
This isn’t about company size. It’s about organizational complexity.
What success actually looks like
When a marketing platform is working well, a few things change in measurable ways.
Marketing can ship experiments in days instead of weeks. Engineers spend less time on one-off changes and more time improving shared systems. Design sees consistency in production without constant oversight. The cost of change goes down.
That’s the real return on investment.
Not that you shipped one page faster, but that you can keep shipping, learning, and adapting without hitting friction every time.
Speed and structure are not opposites
The tension between speed and foundations is understandable, especially in an AI-driven world.
But structure is not the enemy of speed. It’s what makes speed sustainable.
This isn’t an argument against AI, or against code-first workflows. It’s an argument for choosing them deliberately, based on how your team actually operates and where you want to be in a year.
You can optimize for shipping quickly today.
Or you can build a system that keeps letting you ship quickly as the organization evolves.
Both are valid choices.
They just lead to very different futures.
Leave a Reply