CMS as an execution bottleneck in modern GTM systems

I have been building websites directly in code and markdown since early this year because CMS-based setups repeatedly failed under real execution pressure.

The issue was and always has been that CMS systems introduce structural friction that slows motion by default. Once content velocity, SEO structure, and go-to-market execution matter, CMS stops being an enabler and becomes a blocker. Luckily, tools like Cursor make CMS obsolete, so I've been able to completely drop them.

CMS systems are built around separation. Content is created in one interface, structure is defined in schemas that drift over time, rendering logic lives in frontend code, and SEO logic is split across fields, plugins, and conventions. Publishing is controlled through permissions and roles. This separation forces work to move between people and functions even when the change itself is trivial. The result is coordination overhead that compounds with every additional page, template, or stakeholder.

This is not theoretical. Lee Robinson’s analysis documents what happens when teams add CMS layers to manage content more “cleanly.” The system grows preview environments, caching logic, syncing mechanisms, asset pipelines, and user management. None of this improves content quality or outcomes. It increases complexity. His framing around complexity budgets is the key insight. Every abstraction consumes budget. CMS tools consume a large portion of that budget before anything ships. Once the budget is spent, velocity collapses.

The core failure of CMS is that it optimizes for editing comfort instead of execution speed. That tradeoff might make sense for large editorial organizations. It does not make sense for teams where content is tightly coupled to strategy, product narrative, SEO architecture, or go-to-market execution. In those contexts, content is not a loose collection of pages. It is structured data with rules, relationships, and reuse requirements.

Modern websites are systems of entities. Problems, use cases, industries, frameworks, comparisons, and playbooks are not free-form text blocks. They are structured narratives that need consistent templates, deterministic generation, and predictable internal linking. A CMS treats these as fields that humans must keep consistent by process. Code treats them as models that the system enforces by design. This difference determines whether programmatic execution is possible.

This is where CMS becomes incompatible with programmatic go-to-market.

My GTM30 framework assumes that the website itself is an execution engine. Pages are generated from explicit entity models. Internal linking is systematic. Structure is machine-readable. Iteration needs to be cheap. CMS systems resist this at every layer. Schema changes require coordination. Field sprawl grows over time. Logic duplicates between CMS and frontend. Strategy fragments across tools. Teams end up managing the CMS instead of executing go to market.

When content lives as markdown in the same repository as the site, these problems disappear. Content, structure, SEO logic, and deployment operate within one system. Changes are explicit, versioned, and shipped through the same pipeline. There is no parallel workflow to maintain and no abstraction layer that needs to be negotiated with. Automation becomes straightforward because content behaves like data, not like UI state.

This shift is not about aesthetics or developer preference. It is about removing execution friction. CMS-heavy setups introduce role-based bottlenecks, approval latency, and context switching because the system requires them. Code and markdown remove those constraints by collapsing execution into a single surface. Content is written once, structure is enforced once, and changes ship without translation between roles.

CMS is not a neutral infrastructure. It encodes assumptions about how work should move. For execution-heavy teams, those assumptions are wrong. The system slows iteration, blurs ownership, and taxes velocity. That is why I no longer use CMS for websites tied to growth, SEO, or go-to-market execution.

Code and markdown are not a step back. They are the only setup that scales motion without scaling coordination.