Liberating Limits – The Inverse Logic of Build Versus Buy for CMS

Your next content management system presents a decision between building and breaking or buying and boundaries.

This piece was written and edited solely by a human without assistance from artificial intelligence.

Reinventing the wheel.

After decades managing content in both “built” and “bought” systems, I realize now why built – bespoke, home-rolled, or in-house – content management systems showed less success for me than better performing bought – acquired, commercial, or open source – systems.

The criticality of a decision to build or buy a CMS today is elevated as LLMs and artificial intelligence tools provide the opportunity and ability to prompt your way into disaster.

The success I’ve seen with acquired systems might appear to be due to sheer luck, enforced adoption, or begrudging familiarity, but prolonged use reveals another counterintuitive reason:

It’s about the boundaries a bought CMS brings with it at the start.

The Creative Context of Build Versus Buy

Any scenario that enables creativity without limits is of a different nature and a different sequence of complexity than a scenario that allows for creativity within understood limits.

A lack of initial limits introduces later complexity; contrarily, initial limits reduce later complexity.

Developing or acquiring a new content management system presents a stark choice between involuntarily creating new, unknown limits later; or committing to creating within prior, known limits early on.

From Development to Disappointment

Ironically, engineering a brand new content management system, without previous limits, is less challenging but more risky. Open-ended CMS development eventually creates insidious, lurking restrictions around daily operations and long-term productivity. As blue-sky thinking plays out and greenfield features sprawl, overcomplication and user frustration compound.

Interfaces deteriorate and obfuscate. Schemas veer away from core concepts. Content transforms without explanation. Adoption friction is waved away with thick, tedious training binders. The momentum of a bad system grows unstoppable.

From Acquisition to Adaption

Conversely, initial limits bring about truly creative solutions. An acquired content management system steers you into whatever permissioning, modeling, authoring, tagging, publishing, workflows, translating and aggregating configurations it bestows. These restrictions inspire innovative directions as a team works within the system.

The limits of an acquired CMS can be known early on or identified beforehand. Within the walled garden, you cannot necessarily code your way out of a particular predicament. But over time you learn to work more creatively and productively. Adoption becomes adaption.

The Built CMS: Bespoke then Broken

A CMS buildout project opens the floodgates for all kinds of unbounded initial creativity – and commensurate ongoing chaos. I’ve seen some built CMSes show signs of permanent failure within the first 6 weeks to 6 months of operation.

Some of the worst – botched and bloated – content management systems I’ve encountered were built in-house. They promised dedicated, org-specific solutions, tailored to nuanced use cases. Instead, what was promised as an elegant preparation of Tuscan entrées quickly sprawled into splatters of spaghetti.

Prominent examples from my career where I’ve seen CMS development lead to disappointment:

• The “Package Manager” CMS at circa 2000 LAInsider.com (Cox Interactive Media) brought the worrying prospect of instantly deleting about one in every ten carefully and time consumingly prepared publication bundles – AKA packages – as you pushed them to production, earning the system the monicker “Pac-Man”. No backups or recovery … just start over and redo all your work from scratch.

• The custom CMS at O’Melveny and Myers LLP required a delicate drag-and-drop publication action, through a fractalized directory tree interface, straight into a production database, after which the tree would instantly collapse, with no margin for error, nor any confirmation of success. A misdirected publication required taking an elevator upstairs to ask an engineer to retrieve and relocate misdirected content.

• The CMS for the website of KCAL 9 News in Los Angeles (Young Broadcasting), a major metropolitan news source, was built over the Zope application server and choked on minor markup or formatting changes in content, spewing cryptic error messages at random on site pages. The reaction of one developer summoned overnight to fix this issue: “Just inputting content shouldn’t do that …”

• A technical enterprise built a custom JavaScript CMS, over a commercial DMS, that published through a double headless architecture, via a second commercial CMS, to a custom SPA. Content was sharded and scattered. Upon publication, content entered a maze of murky microservices with spasmodic observability. Data was disrupted and diluted in a system stricken with chronic instability.

The Bought CMS: Born with Boundaries

Hundreds of content management systems are available for acquisition. Interestingly, taking on a routine commercial off-the-shelf CMS or open source CMS bestows the critical long-term advantage of limits that are known from the start.

Some of the best – basic and boring – content management systems I’ve experienced were brought in on short notice and with suprisingly little pre-evaluation. These were acquired solutions that grew beloved in the restrained simplicity of their functionality.

While the code of a built system taxes you into perpetual technical debt, a lowest common denominator or dumbed down and acquired content management system enforces a functionality diet and feature budget, forcing you to work more efficiently within your technical means:

• Acquired systems I’ve worked with included Box, Drupal, dotCMS, Wordpress, Movable Type, Textpattern, SquareSpace, Tektronix NewStar and WorldNow.

• Over tens of thousands of content actions, they humbly stored, versioned and published content. They were stable, observable workhorses.

• Extra workflow steps or intermittent manual workarounds could be forgiven because outcomes were reliable and predictable.

• Quaint interfaces and dumbed down layouts could be forgiven because when you worked in them you still felt at home.

• Missing or off-the-mark features weren’t a cause for unfulfilled yearning. Through their power, surrounding capabilities filled the gap.

Leaving Behind a Built CMS

It is awkward and anguishing to retire a botched, bespoke CMS. The people who built it are nearby, and may be attached to it with pride, stubbornness or arrogance to the sunk costs of their failed endeavor. Sponsors and suppliers are incentivized to prolong the system’s miserable lifespan by a codependent break-fix maintenance culture.

Tragically, the content management system that was custom built always seems live to fight another day regardless of the fresh wounds it sustains – and the lingering pain it inflicts.

The true sin is not admitting failure, but admitting failure far too late.

I’ve seen several factors doom built content management systems:

• Dysfunctional program governance where lines among business, product, design and engineering are unclear or unhealthy and prevent the best org outcomes.

• Feature Factory teams of product manager order takers blindly building a business or customer wish list outside a sustainable value or viability proposition.

• Separation of the builders of the system from its operators – content authors and administrators – leading to convoluted, counterproductive feature soups.

• Aloof project players scolding stakeholders for speaking openly about critical or even minor issues; and discouraging data as a neutral way to defuse disagreement.

• Heavily engineering-driven shops in which supremely empowered developers code a straightjacket of technical arcana around the CMS and bottleneck its support.

• Headless implementations – already unwieldy by nature – exacerbating development disjointedness and impeding core content management actions.

• Management reluctant to pull the plug on an incorrigible content system even as problems metastasize and millions of dollars go wasted on futile features.

Learning Limits from Outside, Early On

How is it that complete strangers behind commercial and open source systems deliver much more usable products, with better outcomes, than the tangle of code, tables and interfaces we concoct ourselves within our own enterprises?

The people who build these outside systems bring value through their collective, learned experience, working with a range of other customers and users, across permutations of use cases beyond what we ourselves could anticipate internally.

When your acquired CMS arrives, it carries refreshing ideas, a particular vision, the efficiencies of its creators’ prior learnings, quality tested through real-world repetition – and, crucially, the guardrails that will sustain its operation.

A commercial CMS – even an expensive one – lets us fail fast and cheaper over the long term, even if the up-front cost was quite significant. If we tire of an acquired CMS, it is ultimately disposable and we can walk away from it more easily than an enmeshed custom CMS.

It’s not so much an acquired or bought CMS as a borrowed CMS.

Balancing Build Versus Buy

Criticisms notwithstanding, there is a tradition of organizations attempting to build their own dedicated content management systems. This still seems appropriate if it is done as a bounded experiment for some kind of category defining advantage.

None of this is to say that you also can’t still customize or configure an acquired system in narrow ways to meet a niche need. And of course, there are already all kinds of irresponsible ways to still run any commercial or open source system into the ground.

In the end, even the sunsetting of a bought content management system is a blessing rather than an extinction event. The termination of an acquired CMS provides a new opportunity to bring in fresh learnings from outside the organization that you didn’t have time or money to gather yourself.

A New CMS is About Which Limits, and When

Before you arrive at your next CMS, ask yourself: Do you want to learn new limits the harder way, from the inside, and over a longer period? Or do you want to have predetermined limits shown to you the easier way, from the outside, and early on?

A CMS determination carries a special reminder that today’s artificial intelligence vibe coding practices risk conjuring up sudden, mercurial systems that deteriorate in production through their lack of conceptual grounding.

Your next content management system can be built to break, or it can be born with boundaries.

Whether your CMS limits are ultimately disappointing or liberating is up to you.