Everything Is a Platform Now, Including Your Internal Tools

There is a specific moment in an engineering organisation when an internal service crosses a line. It was built for one team, a second team started calling it, and now a third has a hard dependency on behaviour the original authors considered an implementation detail. Nobody announced this. There was no design review. But the service is now a platform, and the rules changed.

What changes at three consumers

With one consumer, you can change anything by walking over and telling them. With two, you coordinate. With three or more, coordination costs exceed the value of most changes, and the service starts calcifying around whatever accidental behaviour its consumers depend on.

The failure is rarely technical. It is that the owning team keeps operating with application-team habits: shipping breaking changes behind a version bump nobody reads, treating undocumented behaviour as changeable, and prioritising their own roadmap over consumers who now cannot ship without them.

The minimum platform posture

• A contract that is written down and versioned, including error shapes and rate limits, not just happy-path fields.
• A deprecation policy with real dates, communicated where consumers will see it, with usage metrics that tell you who is still on the old path.
• An availability commitment, even an informal one, so consumers know whether to build retries or a fallback.
• A support channel with an owner, because the alternative is that every question becomes a direct message to whichever engineer answered last time.

Golden paths beat mandates

Platform teams that succeed do it by making the supported route the easiest route, not by forbidding alternatives. A template that provisions a service correctly in five minutes wins adoption; a policy document forbidding non-compliant services generates workarounds. If teams route around your platform, that is data about the platform, not about their discipline.

Internal platforms compete with the option of doing it yourself. That is a competitor with excellent product-market fit and no meetings.

Knowing when not to

The opposite error is treating every shared library as a platform and burying a two-file utility under governance. The test is dependency risk: if your service being down or changing shape blocks another team from shipping, you are a platform. If they can copy the code and move on, you are a convenience.

Apply the ceremony where the risk actually is, and let everything else stay lightweight.