Build, Buy, or Compose: Where Should Product Capability Come From?

The oldest question in product engineering has changed shape - and most roadmaps haven't noticed.

Every product team eventually asks the same question about its next capability: do we build this, or do we buy it?

For years that was a genuine binary. Building meant control and cost. Buying meant speed and compromise. Teams argued, chose, and lived with it.

That binary is gone.

Modern products are not built or bought. They are composed - assembled from managed services, platforms, models and open components, joined by the engineering that makes them behave like one product.

The interesting question is no longer "build or buy?"

It is: what must we own, and what should we assemble?

Look inside any serious product today and you will not find a clean answer to "did they build it or buy it?"

The authentication may be a service. The data platform may be managed. The intelligence may come from a model the team did not train. The workflow, the experience and the judgment that hold it all together are the team's own.

Composition is not a compromise between building and buying. It is a third way of creating capability, with its own economics and its own engineering discipline.

Teams that still frame decisions as build-versus-buy tend to make two opposite mistakes: they build things the market has already solved, or they buy things that quietly were their product.

The reason the binary collapsed is that the frontier between "you must build this" and "you can adopt this" has moved - and it keeps moving.

Capability that once demanded a specialist team - search, speech, document understanding, generation, forecasting - can now be composed from mature building blocks.

AI accelerated this more than anything before it. Raw capability has never been this accessible.

But the frontier's movement has a second, less obvious effect: when capability becomes easy to adopt, it stops being a differentiator.

Whatever everyone can compose, everyone will.

Which means the things that make a product worth choosing migrate up the stack - into the experience, the data, the judgment about what good looks like, and the way the assembled parts behave as one.

Sourcing decisions become tractable when you ask two questions about the capability in front of you:

How specific is this problem to our product?

How much does it differentiate us?

Together they form a simple map with four honest answers.

Standard problem, supporting role → Buy. The market has solved this. Adopt it, integrate it well, and spend your engineering nowhere near it.

Standard problem, defining role → Compose - and own the experience. The parts are commodities; the composition is not. Assemble proven components, but own how they come together, and own what the user feels.

Unique problem, supporting role → Question it. If it is truly yours alone but does not differentiate you, ask the harder question: why does it exist at all? Simplify before you build.

Unique problem, defining role → Build. This is your product. Own it end to end - the capability, the data it learns from, and the experience it powers.

The map is not static. The frontier moves left over time: what is unique today becomes standard tomorrow. A sourcing decision is not a decision you make once.

The seductive mistake is treating composition as the easy option.

Assembled capability still has to behave like one product. That is engineering, and it accumulates its own debts when it is skipped.

Integration debt. Every composed component brings assumptions - about data shape, latency, failure behavior, identity, versioning. Left unmanaged, the seams become the product's weakest surface.

Exit cost. Every dependency is a future decision. The question is not "can we adopt this?" but "what would it cost to leave?" Teams that never ask pay the answer later, with interest.

Behavioral evaluation. A composed capability was not built by you, but its behavior in your product is yours. It needs the same evaluation net as anything you build: what does good look like, and how would we know if it drifted?

Boundary ownership. The most important thing a composing team owns is the boundary - the contracts, validations and controls where assembled capability meets your product. Own the boundary and you can change almost any part behind it.

Across every quadrant of the map, four things should never be delegated:

The experience - how the capability feels, fails and earns trust in your product.

The data - what the product learns from use, and the right to keep learning from it.

The evaluation - your definition of good, measured continuously, independent of any component's claims.

The boundaries - the contracts and controls that let you replace any assembled part without rebuilding the product.

Own these four, and most sourcing decisions become reversible. Give them away, and even a "buy" decision quietly becomes a rebuild.

Stop running build-versus-buy debates. Run ownership debates: place the capability on the map, decide what must be owned, and let the sourcing answer fall out.

Re-examine the map on a cadence. The frontier moves; last year's build may be this year's compose.

Budget for composition as engineering, not procurement. The seams, the evaluation and the exit paths are real work - cheaper than building, never free.

And when a capability sits in the defining row of the map, be honest: if it defines you, it deserves your engineers.

The teams that get this right are not the ones that build the most, or buy the fastest.

They are the ones that know, at any moment, exactly what they own and why.

Talk it through with engineers who build, buy and compose every week - and who will tell you honestly which one your product needs.