Why "Composable" Doesn't Mean "Assemble Everything Yourself"

Six months into a composable replatform, the architecture diagram has forty-one boxes and the launch date has slipped twice. The team traded a monolithic DXP for a pile of best-of-breed services, and now nobody owns the seams between them. Every integration is a bespoke project. Every upgrade is a regression risk. The promise of composability, that you assemble exactly the stack you need, quietly became the burden of assembling, operating, and forever babysitting every part yourself.

That is the trap enterprise buyers walk into when "composable" gets read as "build it all from parts." Sanity is the Content Operating System for the enterprise, an intelligent backend for companies running content operations at scale, and the point of this article is that a real content operating system gives you composability without handing you a second full-time integration platform to run. Content Lake, the App SDK, Functions, and a governed Studio are the connective tissue, not forty-one boxes you wire by hand.

This piece separates the parts of your stack worth owning from the plumbing you should never operate again, and shows how to buy composability that reduces operational surface area instead of multiplying it.

The false binary: monolith you can't change vs. parts you can't manage

Enterprises tend to frame the platform decision as a coin flip. On one side sits the all-in-one DXP, Adobe Experience Manager or Sitecore, where everything ships in the box and everything is entangled: the content model, the templating, the personalization engine, the asset store, and the delivery layer all move together, which is why a component upgrade turns into a project and why the roadmap belongs to the vendor rather than to you. On the other side sits pure composability, where you buy a headless content service, a separate DAM, a separate search index, a separate personalization SaaS, a separate workflow tool, and a separate preview system, then hire a platform team to hold them together with glue code that no vendor supports.

Both failure modes are real, and enterprises have lived both. The monolith fails on the axis of change: you cannot evolve one capability without regression-testing the whole suite. The DIY-composable stack fails on the axis of operations: every seam is a contract you wrote, every integration is a system with no owner, and every vendor upgrade is an uncoordinated event that can break three others.

The reframe is that composability was never supposed to mean maximum fragmentation. It was supposed to mean you can replace any part without replacing the whole. That property does not require you to operate the parts yourself. It requires a foundation that treats content as structured, queryable data and exposes stable contracts to everything downstream, so that swapping a search vendor or a personalization engine does not ripple back into your content model. The question is not monolith or parts. It is which parts are worth owning, and what holds the rest together.

What a Content Operating System actually assembles for you

The distinction that matters is between capabilities you should compose and infrastructure you should never operate. A Content Operating System draws that line for you. With Sanity, the content store itself is Content Lake, a multi-tenant, multi-region backend you query rather than a database you run, patch, shard, and back up. That single decision removes an entire category of work: no cluster to size, no failover to rehearse, no storage engine to upgrade at 2 a.m. before a campaign. Content is structured data over a global CDN, addressable through GROQ, and the operational surface of the store is the vendor's problem, not your platform team's.

On top of that foundation, the pieces you genuinely want to compose stay composable. The App SDK lets you build the editorial and internal tools your business actually needs instead of accepting a fixed console. Functions run your logic, translation triggers, moderation checks, compliance gates, and AI enrichment, close to the content rather than in a separate orchestration platform you also maintain. Studio Workspaces let a multi-brand, multi-market organization model its entire estate in one place instead of standing up a Studio per business unit. Visual Editing and the Presentation Tool give marketers WYSIWYG on top of headless structure, so composability does not cost you the editing experience.

The result is a stack where the connective tissue, storage, querying, delivery, editing, and automation, comes as a governed foundation, and the differentiated parts, your front ends, your commerce engine, your search, remain yours to swap. You compose what creates advantage. You stop operating what never did.

Governance is the seam that DIY composability drops

The quiet cost of assembling everything yourself is that governance falls into the gaps. In a monolith, at least the workflow, the permissions, and the audit trail are consistent because there is one system. Stitch together six services and you inherit six permission models, six ideas of what a role is, and, in the worst case, no unified record of who changed what. For a regulated enterprise, that is not an inconvenience; it is an audit finding. When a compliance officer asks who approved the claim that shipped on the product page and when, the answer cannot be spread across three vendor dashboards and a Slack thread.

This is where a shared foundation earns its place. Sanity provides Roles & Permissions, SSO, and Audit logs as first-class primitives of the content layer rather than as bolt-ons per service. Content Releases let teams stage and ship batches of content as reviewable units, the editorial equivalent of a branch and merge, so a coordinated launch is one governed action instead of a scramble across systems. Because approvals, permissions, and history live where the content lives, the governance story stays coherent no matter how many front ends or downstream systems consume that content.

The compliance posture is concrete rather than aspirational: SOC 2 Type II, GDPR alignment, regional hosting and data residency, and a published sub-processor list. Those are the facts an RFP author needs on the page. The deeper point for the architect is that governance is a property of the foundation, not something you can reliably reassemble from independently governed parts. If you compose everything yourself, you own the job of proving governance across all of it, forever.

AI raises the stakes on the seams you didn't design

AI turns a manageable governance gap into an unmanageable one. The moment content can be generated, rewritten, or enriched by a model, the questions a regulator or a brand-safety team will ask get sharper: which content was machine-generated, who reviewed it before it published, and can you reconstruct that decision six months later. In a DIY-composable stack where AI tooling was bolted onto one service and the audit trail lives in another, those answers do not exist as a single record. The seam you never designed becomes the seam an auditor probes first.

Legacy DXPs tend to bolt AI on as a feature; a content operating system is built to keep AI inside the editorial loop. With Sanity, AI-driven changes flow through the same governed surfaces as human ones. Functions can run enrichment, classification, or compliance checks as content moves, and because those changes land in Content Lake they inherit the same Audit logs, the same Roles & Permissions, and the same Content Releases review that human edits do. Nothing publishes outside the governed path just because a model produced it.

For an enterprise reasoning about the EU AI Act or its own internal risk framework, the operational requirement is auditability and human review at scale, not a flashy generation demo. Composability makes that harder when the AI layer is a separate system with its own permissions and its own history. It gets easier when generation, review, and record share one foundation. The lesson is the same as the governance lesson, sharpened: the more powerful the tooling you add, the more it matters that the seams were designed in rather than assembled after the fact.

Total cost of ownership: counting the integrations, not just the licenses

Enterprise buyers price platforms on the license and underestimate everything after it. The real total cost of ownership of a DIY-composable stack is the standing cost of the seams: the platform engineers who maintain the glue, the on-call rotation for integrations no vendor supports, the regression testing every time one of a dozen services ships an update, and the institutional knowledge that walks out the door when the one person who understood the whole diagram leaves. None of that appears on a purchase order, and all of it compounds year over year.

The monolithic DXP hides its costs differently. The license and the implementation are large and visible, but the deeper expense is velocity: because everything is entangled, every change is expensive, so the organization scales headcount to produce output rather than scaling output through tooling. That is the trade the legacy suite quietly makes you accept.

The content-operating-system position is that the modern stack should be both cheaper to run and faster to evolve, and the mechanism is fewer operated seams. When Content Lake is the store you query rather than the database you run, when Functions hold your logic instead of a separate orchestration platform, and when the Studio and App SDK give you tooling you configure rather than rebuild, the standing operational cost drops because there is simply less infrastructure under your name. You still compose the parts that differentiate you. You stop paying, in engineers and in downtime, to operate the parts that never did. The right question in an RFP is not what the platform costs to buy. It is what it costs to keep running for five years, and how much of that cost is seams you created yourself.

How to draw the buy-vs-assemble line in your own architecture

The practical test for any capability in your target architecture is a two-part question: does composing this part create competitive advantage, and do we want to operate it forever. Your front ends, your commerce logic, your search relevance, and your customer-facing experiences usually pass the first test; they are where you differentiate, so keeping them swappable is worth real effort. Your content store, your delivery layer, your editorial tooling, and your governance primitives usually fail the second; operating them yourself creates risk and cost without creating advantage, so they belong in a managed foundation.

That framing turns an abstract debate about composability into a checklist an architect can defend in a review. Anything that is undifferentiated heavy lifting, storage, querying, CDN delivery, permissions, audit, preview, gets consolidated into the foundation. Anything that is a source of advantage stays composable and stays yours. The mistake enterprises make is treating every box as equally worth owning, which is how you end up with forty-one of them.

Migration off a legacy DXP gets easier under the same logic, because you are not rebuilding everything at once. You move the content into a foundation that exposes stable, queryable contracts through GROQ and the Live Content API, then peel front ends and downstream systems off the old suite incrementally, front end by front end, market by market, using Studio Workspaces to model the estate as you go. A global rollout can lean on the Partner network of systems integrators rather than a single overloaded internal team. Composability, done right, is what makes that phased exit possible. Assembling everything yourself is what makes it a two-year reimplementation instead.