CONCEPT Cited by 1 source
Build-vs-buy for CMS¶
Definition¶
Build-vs-buy for CMS is the architectural decision a platform-engineering team makes when it needs editorial content-management capability for its product surfaces — between building a CMS in-house and buying a commercial (headless) CMS and integrating it into the internal platform.
Why this decision is distinctive¶
Unlike most build-vs-buy decisions, the CMS-specific version is dominated by scope risk, not feature gaps. CMS requirements tend to grow with the product roadmap — new authoring workflows, new content types, new localisation targets, new collaboration affordances, new preview / review / staging semantics. A team that starts with a minimal in-house CMS finds the scope grows without an obvious stopping point.
Zalando's landing-pages team names this exact concern in the post rationale:
"We were also conscious that trying to reinvent the wheel by building our own CMS could grow into a project with limitless scope that we would never finish."
(Source: sources/2022-09-28-zalando-more-editorial-content-please)
The decisive properties on the buy side¶
In Zalando's case, the decisive properties for Contentful were:
- Flexible, extensible content model — arbitrary entry-type schemas, validation rules, and reference structures the team could shape to its needs.
- Scalable in what content can be served — no ceiling the team could see bumping into as product surfaces proliferate.
- Easily extensible CMS UI via custom apps — the company can graft domain-specific authoring affordances onto the vendor's UI without forking the CMS.
- Strong multi-language support out of the box for 25-market localisation.
- Bigger-team collaboration features — roles, workflows, content review.
The buy-side trap this decision avoids¶
The complementary trap is picking a rendering-coupled CMS (one that dictates the presentation tier). Zalando's choice is headless — the CMS owns authoring, the company owns delivery. That preserves the optionality a build-vs-buy reasoning is trying to protect and makes the proxy wrapper pattern (patterns/proxy-layer-for-external-saas) applicable as an isolation layer.