Platform Reuse Rate — Are systems compounding or fragmenting?
Platform reuse rate is the signal that most directly measures whether architectural investment is translating into actual usage.
It is easy to invest in a platform. It is much harder to build one that teams actually use. A platform that exists but is not used is not a platform — it is overhead with documentation and no return. Platform reuse rate is the signal that distinguishes between the two.
What this signal measures
Platform reuse rate measures the proportion of new capabilities that are built on top of existing shared platform components rather than built from scratch or sourced from external systems.
In practical terms: when a team needs to add a new feature that involves customer identity, do they use the shared identity platform or build their own implementation? When a team needs to send a notification, do they use the shared notification service or implement their own? When a team needs to process a payment, do they extend the existing payment platform or introduce a new integration?
Each of those decisions is a data point. Aggregated across teams and over time, they produce a reuse rate — and that rate reflects whether the system is building on itself or around itself.
A rising reuse rate means the platform is earning adoption. Teams are finding it easier to build on top of what exists than to build from scratch. The platform is ahead of demand, or at least keeping pace with it. The architectural investment is compounding.
A falling reuse rate means the platform is losing adoption. Teams are finding it easier — or necessary — to build around the platform rather than on it. The gap between what the platform provides and what teams need is growing. The architectural investment is not returning what it was designed to return.
How to read it correctly
Platform reuse rate is easy to misread in two directions.
The first misreading is treating a high reuse rate as unconditional evidence of platform health. A high reuse rate can reflect genuine platform fitness — teams are using the platform because it genuinely serves their needs. It can also reflect enforcement rather than adoption — teams are using the platform because they are required to, even when it does not serve their needs well. These two situations produce the same metric but represent fundamentally different system states. A platform that is adopted because it is good will produce falling marginal cost and rising delivery velocity. A platform that is adopted because it is mandated will produce compliance friction, workarounds at the margins, and eventual bypass when delivery pressure is high enough.
The correct way to distinguish between them is to look at what teams are doing at the boundary of the platform — where they are extending it, where they are requesting changes to it, and where they are building local workarounds that technically comply with the platform-first policy while avoiding the parts of the platform that do not serve their needs. Those boundary behaviors are more informative than the headline reuse rate.
The second misreading is treating a falling reuse rate as evidence of poor team behavior. When platform reuse rate falls, the instinctive response is to enforce the platform-first policy more aggressively — to require teams to use the platform and to treat bypass as a governance failure. Sometimes that is the right response. More often, falling reuse rate is a platform fitness signal: the platform is not keeping pace with what teams need, and teams are finding alternatives because the alternatives work better.
The question to ask when reuse rate falls is not “why are teams bypassing the platform?” It is “what is the platform failing to provide that makes bypass the better option?” The answer to that question is the platform roadmap — and it is more valuable than any enforcement mechanism.
What it reveals when it moves
A rising platform reuse rate, sustained over multiple quarters, reveals that the architectural investment is compounding. Teams are building on top of shared foundations rather than rebuilding them. Integration complexity is being contained. The marginal cost of new capabilities is falling — because each new capability is extending what exists rather than adding to what needs to be maintained.
A rising reuse rate also reveals alignment between architecture and demand. Teams use platforms when it is easier to use them than to build around them. When reuse rate rises, it means the platform is ahead of the demand curve — it is providing what teams need before they have to solve the problem themselves. That is the condition that produces genuine platform adoption rather than mandated compliance.
A falling platform reuse rate reveals one of three structural conditions, and the structural response depends on which one it is.
It may reveal platform under-investment. The platform is not keeping pace with what teams need. This is a capital and sequencing signal — the foundational investment bucket has not been adequately protected, and the platform is falling behind the demand it was supposed to support.
It may reveal platform design drift. The platform was designed for the organization’s needs at a point in time, and those needs have evolved. The platform has not evolved with them. This is an architectural signal — the platform roadmap needs to be reset against the current operating model, not the one that existed when the platform was designed.
It may reveal enforcement failure. The platform is capable, the design is current, but teams are bypassing it anyway because the platform-first policy is not being enforced. This is a governance signal — and it connects directly to the mandate issues described in Part I and the no-holding framework in Part III.
Each of these requires a different response. A falling reuse rate that is diagnosed as platform under-investment and treated as an enforcement failure will produce compliance without adoption — and the underlying problem will continue to grow beneath the surface of apparent compliance.
What to do when it moves in the wrong direction
When platform reuse rate is falling, the first response is diagnosis, not enforcement.
Map where reuse is falling. Is it falling uniformly across all teams, or is it concentrated in specific teams, specific capability areas, or specific types of initiative? Uniform decline points to platform-wide under-investment or design drift. Concentrated decline points to a specific gap between what the platform provides in a particular area and what teams in that area need.
Once the pattern is mapped, the CTO needs to determine which of the three structural conditions — under-investment, design drift, or enforcement failure — is driving it. The friction signals from the weekly cadence and the architectural stress assessments from the monthly review should contain the evidence. Teams that are bypassing the platform will leave traces — local implementations of capabilities that the platform is supposed to provide, integration patterns that work around platform interfaces rather than through them, workarounds that appear in the friction signal log.
If the diagnosis is under-investment or design drift, the response belongs in the quarterly capital session. The falling reuse rate is the economic argument for platform investment — translated into business terms, it represents rising marginal cost, increasing integration complexity, and growing technical debt. The CTO who arrives at Session 2 with a specific calculation of what the falling reuse rate is costing the organization in duplicated effort and rising integration overhead has a capital argument, not a technical one.
If the diagnosis is enforcement failure, the response belongs in the mandate conversation. A platform-first policy that is not being enforced is not a policy. The CTO needs to determine whether the enforcement failure is a governance design problem — the policy exists but there is no mechanism to enforce it — or a mandate boundary problem — the policy exists, the mechanism exists, but the CTO’s authority to enforce it is not holding under organizational pressure. The second is addressed in Part VI.
When platform reuse rate is rising, the structural response is the same as for falling marginal cost: make the cause visible, protect the investment that is producing the improvement, and ensure that the platform roadmap continues to stay ahead of demand. A rising reuse rate that is not actively maintained will plateau, then reverse — as demand evolves past what the platform currently provides and teams begin finding alternatives again.
Five Circles reference: Circle II — Architectural Foundation