A platform is a product only when it has consumers, governance, and measurable leverage

“Platform” is the most inflated word in technical strategy. It gets applied to any system with an API, any set of shared services, and quite often to a monolith someone intends to split later.

The distinction I use is not architectural. A platform product exists when other teams or companies build on your capabilities and could choose not to. Everything else — the microservices, the API gateway, the service mesh — is implementation detail that may or may not support a platform.

The four tests

The diagram above is the whole argument. Fail one gate and you do not have a platform product; you have shared infrastructure, which is fine but is managed differently.

One: a genuinely reusable capability

The capability must serve more than one consumer without forking. The test is not “could it in principle” but “does it, today, for at least two consumers whose needs differ.”

Two consumers is the minimum for a reason. With one consumer you cannot tell which parts of your interface are the capability and which are that consumer’s assumptions leaking through. Abstractions built from a single case are almost always wrong in a specific way: they encode a workflow rather than a capability, and the second consumer arrives needing exactly the thing you hardcoded.

Two: named consumers

You must be able to list them. Actual teams, actual companies, actual products. If the consumer list is “future teams” you are building on speculation, and speculation-built platforms tend to be over-general in the dimensions nobody needed and rigid in the one dimension that mattered.

For internal platforms this test is the most commonly failed, because internal consumers are conscripted rather than acquired. When a team is mandated to use your platform, adoption stops being a signal and you lose the feedback loop that would have told you the interface was wrong.

Three: governance

Governance is not bureaucracy here; it is the actual product. What consumers buy — internally or externally — is the ability to depend on something safely.

That means: an explicit versioning policy; a contract stating what is guaranteed and what is not; a deprecation policy with real notice periods; a support expectation; and a changelog that treats breaking changes as significant events rather than release notes.

Without these, rational consumers respond by defending themselves — wrapping your API in their own adapter, pinning versions forever, or quietly building a parallel implementation. All three destroy the leverage the platform was supposed to create, which is why weak governance shows up as duplicated code rather than as complaints.

Four: measurable leverage

Leverage means the platform makes consumers faster or cheaper, and you can express it per consumer: time to integrate, cost avoided, work not duplicated. It does not have to be a precise number. It has to be a defensible claim.

If you cannot state the leverage, the honest conclusion is that the platform is generating cost, not saving it. Platforms have real overhead — coordination, governance, backwards compatibility, generality you would otherwise skip. That overhead is only justified by leverage that exceeds it.

Internal and external consumers are not the same

The mistake is treating internal platforms as easier because “we control both sides.”

External consumers provide honest signals — they leave, or they never arrive. They also impose hard constraints: you cannot break contracts, migration windows are long, documentation must stand alone.

Internal consumers are captive, which removes the signal that would tell you the product is bad. You get complaints instead of churn, and complaints are easy to dismiss as friction. The compensating discipline is deliberate: treat adoption as voluntary even when it is not. Ask whether a team would choose the platform if they had an alternative, and take “no” as a product defect rather than a training problem.

API design is product design

For a platform, the API is the product surface. Consequential decisions that look technical but are commercial:

• Granularity. Fine-grained APIs are flexible and force consumers to understand your domain model. Coarse-grained ones are easy and constrain use cases. This choice determines who can adopt you.
• Error semantics. What a consumer can distinguish — retryable versus permanent, their fault versus yours — determines how well they can build on you. Undifferentiated errors are a product failure.
• Idempotency and reversibility. In anything touching money or provisioning, these are the difference between a capability you can trust and one you must wrap defensively.
• Backwards compatibility. Every breaking change spends trust. You have less than you think.

Cost, and when not to build one

The costs are real and mostly deferred: coordination between platform and consumers; the ongoing tax of backwards compatibility; generality that will never pay for itself; a support surface that competes with new work; and the slow accumulation of unremovable capabilities, because someone always depends on the part you wanted to delete.

Do not build a platform when: you have one consumer; you cannot name the second; the capability is not stable enough to have a contract; nobody will own governance; or the honest reason is organizational aesthetics — that platform work sounds more strategic than product work.

The alternative is not chaos. Shared libraries, internal services with clear owners, and copy-paste-then-consolidate are all legitimate and often better. Extract the platform when a second consumer forces the abstraction, and let the abstraction be shaped by two real cases instead of one imagined one.

Where I have seen this play out

Telecommunications is a useful example because the platform framing is unusually literal. An MVNO platform exposes provisioning, activation, plan management, and billing as capabilities that other businesses build products on. The four tests are not theoretical there: consumers are named companies, governance failures show up as failed activations, and leverage is directly expressible as time from partner signature to a live service.

It is also a case where the operational floor makes the governance test unforgiving. A consumer integrating against provisioning cannot tolerate a breaking change on short notice, because their own customers experience it as a service outage. That constraint improves platform discipline faster than any internal principle.

Limitations

This is a view from mid-sized companies where platform investment competes directly with product investment for the same scarce engineers. In an organization large enough to fund a platform group whose only job is leverage, the calculus differs — the coordination cost is absorbed structurally and the two-consumer rule can reasonably be relaxed on strategic grounds. I would also distinguish this from two-sided marketplace platforms, where the economics are network effects rather than reuse, and the tests above apply only loosely.