sheet III · strategy 71 / 80

Composability

Компонуемость

Speed and scale Holds Depth 3 · Drill rig

components assemble in many configurations

Moats it grows into

  • #20 Developer ecosystem 3 · Drill rig

    Parts that assemble in many configurations are what developers build on; each thing they build is capital sunk into your primitives, and their sunk cost is your Developer ecosystem.

  • #6 Integrations 2 · Excavator

    Every configuration that reaches into another tool is an Integration you did not have to write, and the breadth of those connectors is what a rival has to rebuild.

Summary

Composability is exposing your product as parts that others assemble in ways you did not plan: an API, a set of primitives, a pipe that fits any other pipe. The edge is that every assembly someone else builds is a reason to stay and a connector you did not have to write. It holds through a Developer ecosystem and through Integrations.

How it works

The mechanism is other people's work accumulating on your side of the fence. When your product is a set of parts with a clean interface, a developer combines them into something you never specified — a checkout flow, a billing model, a workflow between two other tools. That combination is now their product, running on your primitives, and replacing you means rebuilding every combination, not just switching a vendor. The more assemblies exist, the more expensive leaving becomes for the people who built them.

The interface does the work. It has to be stable enough that a combination built last year still runs, general enough that combinations you did not foresee are possible, and documented well enough that a stranger builds one without asking you. Every constraint you remove from how the parts fit together adds a configuration someone will build. Every breaking change you ship destroys a set of them and teaches the builders to hedge.

Why it holds — or only takes

Composability holds because the assemblies are built by others and paid for by others, and they stay where they were built. That is a Developer ecosystem: third parties invest on top of you, and their investment becomes your wall — a two-sided network effect plus their own switching cost working in your favour. Each assembly that reaches into another tool is also an Integration, a connector you did not write but your product now carries. The ecosystem is a drill rig and resists AI; the integrations are an excavator and under attack, because an agent can now generate a connector in an afternoon. The hold rests on the first.

Do you have it

  • Developers use your parts for things you never documented, and you find out from their launch posts.
  • A breaking change would break products other companies sell, and you know which ones.
  • Your primitives are combined with other tools more often than they are used alone.
  • The reference docs get more traffic than the marketing site.

How to dig it

  • Ship primitives, not features: a charge, a message, a record, each usable without the others.
  • Freeze the interface early and version it; a combination built on you has to keep running for years.
  • Document for the stranger: a developer should build the first assembly without emailing you.
  • Publish the assemblies others build, so the next builder starts from a working combination.
  • Never ship a breaking change without a migration path; each one teaches builders to hedge against you.

How it erodes

  • A standard emerges for the interface and your parts become interchangeable with a rival's.
  • An agent generates the connectors in an afternoon, so the integration breadth no longer costs anyone anything.
  • You start competing with the assemblies built on you, and the builders move their work to a neutral base.
  • Breaking changes pile up until developers wrap you behind an abstraction that lets them swap you out.

Solo, without capital

Integrations are fully within one person's reach: a clean API, a webhook, a plugin format can be shipped in a quarter and connected to the tools your users already run. A Developer ecosystem is only partly reachable alone — other people have to build on you, and they will not until there is a base of users worth building for. Ship the interface now; the ecosystem, if it comes, comes after the audience. Part of both can be rented from an existing platform, at the cost of building on its ground.

What the matrix says of its moats

In nature, in business

Nature
—
Business
APIs, Stripe

Cases

  • Stripe — Exposes payments as a small set of API objects, so businesses build billing, marketplaces and checkouts it never designed on top of them.
  • Twilio — Turned phone calls and text messages into API calls, and the notification and verification flows developers built on those calls became products of their own.
  • Unix — Made every program a filter with text in and text out, so tools written decades apart still chain together with a pipe.

Combines with

  • Modularity — Independent units are the parts; composability is the interface that lets others assemble them, and the two are dug together.
  • Standardization — A shared interface that others already speak lowers the cost of every assembly built on your parts.
  • Aggregation — An environment built for broad participation gives the assemblies a place to be found and reused.

This strategy on the map → Map this combination →

Fights with

  • Completeness — An all-in-one closes the seams that composability opens; you cannot both own every step and let others assemble the steps.
  • Secrecy — Exposing your parts through a public interface is the opposite of protecting how they work.

Map this tension →

Strategy taxonomy © kepano (Steph Ango), paraphrased with attribution. Role and moat mapping © Moat Atlas. Many ways to win ↗