Informal platform consumption causes rework—build an internal service marketplace

There's a specific kind of chaos that shows up once a platform team starts serving more than three or four product teams. Nothing is technically broken. The platform works. Teams are shipping. And yet every quarter, the platform roadmap gets torn apart by requests nobody agreed to, integrations that "already went live" without anyone signing off, and product teams furious that the thing they built on top of shifted underneath them.

The root cause almost always traces back to how platform capabilities get consumed. Not built—consumed. Most orgs put enormous care into how platforms are architected and almost none into how product teams request, adopt, depend on, and get charged for those capabilities. Consumption stays informal. Someone pings someone in Slack, gets a "yeah go for it," and now there's a production dependency nobody catalogued.

That informality is fine at small scale. At medium scale it becomes the single largest source of rework across both platform and product teams. The fix isn't more meetings or a stricter gatekeeper. It's treating platform capabilities like a real internal service catalog marketplace—with published services, consumption SLAs, cost-to-serve, intake rules, and lightweight contracts that make responsibilities obvious.

Why informal consumption feels efficient right up until it isn't

Early on, informal consumption is genuinely faster. A product engineer needs the notifications service, the platform engineer says sure, and they're integrated by lunch. No paperwork, no queue, no ceremony. Everyone feels productive.

The trouble is that speed is borrowed against future clarity. Every one of those quick "yeses" creates an undocumented dependency, an implicit expectation about uptime, and an assumption about who fixes what when it breaks. Multiply that across a dozen product teams and a platform team that turns over staff, and you've built a dependency graph that lives entirely in people's heads and old Slack threads.

The pattern that shows up consistently: the platform team thinks they support five real integrations. When they actually audit consumption, they find seventeen. Twelve of those were never planned for, aren't load-tested for that traffic, and have zero defined ownership when they page at 2am. The platform didn't fail. The consumption model did.

A few things reliably go wrong once informal consumption compounds:

1. 1
   Capacity surprises. The platform team plans capacity for known load. Undocumented consumers add traffic nobody forecasted, and the first sign is degraded performance for everyone.
2. 2
   Blame ambiguity. When something breaks, product says "platform owns it," platform says "you're using it wrong," and nobody can point to what was actually agreed.
3. 3
   Roadmap hijacking. Product teams treat any platform gap as an emergency request. Without intake rules, the loudest team wins, and the platform roadmap becomes reactive.
4. 4
   Invisible cost. Nobody knows what any given service actually costs to run per consumer, so there's no way to say no to low-value usage or prioritize high-value usage.

The platform didn't fail. The consumption model did.

What actually breaks at scale

The failure modes aren't random. They cluster around four operational pressure points and show up in a fairly predictable order as an org grows.

1. Intake becomes a bottleneck disguised as a favor

At small scale, one senior platform engineer informally handles all requests. That works until they're the human router for everything. Every product team's integration timeline now depends on one person's inbox. That person becomes a bottleneck, burns out, or leaves—and takes the entire mental model of who-consumes-what with them.

2. Reliability expectations diverge silently

Product team A assumes the shared search service is basically always up because it always has been. Product team B knows it has scheduled maintenance windows. Neither wrote anything down. When a maintenance window takes search offline for eight minutes, team A treats it as an incident and escalates loudly, while team B shrugs. Same event, two completely different reactions, because there was never a shared definition of what "supported" actually means.

3. Cost stays invisible and decisions stay political

Without cost-to-serve, every prioritization conversation is an argument about opinions. The platform team can't explain why supporting a niche integration for one team is expensive. The product team can't understand why their "small request" keeps getting deprioritized. This is exactly the terrain covered in our SLA-and-ROI framework for platform vs product roadmap decisions—cost visibility is what turns those debates into actual decisions.

4. Changes break consumers nobody knew existed

This is the most painful one. The platform team ships a reasonable change to a service, and three product teams break because they were consuming it in ways the platform never knew about. If you've dealt with the discipline required around external-facing changes, the same rigor applies internally—the partner integration approach with change windows and acceptance tests maps cleanly onto internal consumers too. Internal consumers deserve change management just as much as external ones do.

The marketplace model: what it actually is

Calling it a "marketplace" sounds fancier than it is. In practice it means five concrete things exist and are visible to everyone:

The point isn't bureaucracy. The point is that consumption becomes a deliberate transaction instead of an implicit favor. A product team can look at the catalog, see what's offered, understand the SLA and cost, and make an informed decision. The platform team gets visibility into who's consuming what and can plan capacity accordingly.

How the workflow changes in practice

The difference shows up in the actual day-to-day flow—that's where the value lives.

Old workflow (informal): A product engineer needs event streaming. They DM a platform engineer. They get a yes. They integrate. Nothing is recorded. Six weeks later the platform team refactors the event service, unaware this consumer exists. It breaks in production. Both teams spend a day firefighting and a week rebuilding trust.

New workflow (marketplace):

1. 1
   Product engineer browses the catalog, finds the event streaming service, sees it's marked stable with a documented SLA (99.5% uptime, best-effort support during business hours, no guaranteed latency under burst load).
2. 2
   They submit an intake request declaring expected volume and use case.
3. 3
   The platform team reviews against the intake rules—is this within current capacity, or does it need forecasting? For standard usage under a threshold, it's auto-approved. For heavy usage, it goes into the prioritization queue.
4. 4
   Consumption gets recorded. This consumer is now a known dependency.
5. 5
   When the platform later plans a change, they can see every registered consumer and coordinate a change window with them.

Here's a simple diagram of the marketplace workflow.

No single step is magic. What matters is that consumption is now legible. You can't manage what you can't see, and informal consumption is essentially the art of making everything invisible.

A real scenario

A mid-sized B2B SaaS company—around 60 engineers split across one platform team and five product teams—kept losing roughly a sprint per quarter to platform-related rework. Not one big failure, just the constant drip of "we didn't know you were using it that way" incidents.

When they audited actual consumption, the platform team believed they supported about nine internal integrations. The real number was closer to twenty-two. More than half had no documented owner on the consuming side.

They didn't build anything elaborate. They published a catalog of their eight core platform services, wrote a one-paragraph SLA for each, attached a rough cost tier (low/medium/high to serve), and set a simple intake rule: anything above a defined traffic threshold needs a forecast and goes through prioritization; everything else is self-serve and auto-registered.

Within about two quarters, the "surprise consumer breaks in production" incidents dropped from a near-weekly annoyance to maybe one or two a quarter—and most of those were genuinely new edge cases rather than unknown consumers. The platform team also killed two low-value integrations they'd been silently subsidizing once cost-to-serve made the tradeoff obvious. Reclaimed somewhere around 15–20% of the platform team's capacity that had been quietly going to unplanned support.

None of that required heavy tooling. It required making consumption visible and agreed.

The intake and prioritization rules that actually hold up

Intake rules fall apart when they're either too heavy (nobody uses them, everyone routes around) or too light (everything is "urgent"). A few principles keep them functional:

1. 1
   Tier by impact, not by volume of requests. Most requests should be self-serve against existing catalog services. Reserve the formal prioritization queue for new capabilities or high-load consumption.
2. 2
   Make the default fast. If standard consumption within limits requires a meeting, teams will bypass the whole system and you're back to Slack DMs.
3. 3
   Require a declared expectation. Every intake should state expected volume, criticality, and who owns the integration on the consuming side. That last one ends most blame arguments before they start.
4. 4
   Publish the prioritization criteria. Product teams stop treating everything as an emergency once they can see how requests are actually ranked.
5. 5
   Revisit deprecations on a schedule. Services marked deprecated need a real sunset timeline and a migration path, not an indefinite limbo where three teams keep depending on something you're trying to kill.

Intake rules work when they're clearly published, fast for normal cases, and require just enough information to make prioritization meaningful.

When this makes sense—and when it doesn't

When it's worth building

1. 1
   You have a real platform team serving three or more product teams.
2. 2
   You've had at least a couple of "we didn't know you were using it" incidents.
3. 3
   Platform roadmap keeps getting derailed by reactive requests.
4. 4
   You genuinely can't answer "who consumes this service?" without an investigation.

When it's a bad idea

1. 1
   You have one product team and one platform team who sit next to each other. The overhead isn't worth it—informal works fine at that scale.
2. 2
   You're pre-product-market-fit and everything is changing weekly. Cataloging services you might delete next month is wasted motion.
3. 3
   Leadership treats it as a compliance exercise rather than an operational one. If it becomes a paperwork ritual instead of a visibility tool, it'll die a slow death and teams will route around it.

Who should not run this

Don't hand the marketplace to a governance committee that doesn't consume or operate any of these services. It has to be owned by the platform team, because they're the ones who feel the pain of invisible consumption and the ones who can actually keep the catalog honest. A detached governance body produces beautiful catalogs that nobody trusts or updates.

Keeping the catalog from rotting

The failure mode of every internal catalog is staleness. A catalog that's 40% wrong is worse than no catalog, because people stop trusting it and quietly go back to Slack. Where operational tooling actually earns its keep is in automating the parts humans forget—syncing real consumption data into the catalog so registered dependencies reflect reality, flagging services whose traffic has diverged from what was declared at intake, nudging owners when an SLA hasn't been reviewed in a while. The catalog stays accurate because the boring maintenance work isn't relying on someone remembering to do it.

But tooling is secondary. Plenty of teams run a perfectly functional version of this in a shared doc and a spreadsheet for a year before they need anything more. The discipline matters more than the software.

“

Automate syncing consumption metrics into the catalog so registered dependencies reflect reality without manual upkeep.

The catalog stays accurate because the boring maintenance work isn't relying on someone remembering to do it.

The shift worth making

The deeper change here isn't the catalog or the SLAs or the intake forms. It's moving from a world where platform consumption is a series of undocumented favors to one where it's a set of visible, agreed relationships. That shift is what turns platform-product friction from a permanent tax into a solvable coordination problem.

Most teams don't have a platform quality problem. They have a platform consumption problem hiding behind good architecture. Make consumption legible, attach real expectations and real costs to it, and most of the rework you've been absorbing simply stops showing up on your roadmap.

The deeper change here isn't the catalog or the SLAs or the intake forms. It's moving from a world where platform consumption is a series of undocumented favors to one where it's a set of visible, agreed relationships. That shift is what turns platform-product friction from a permanent tax into a solvable coordination problem.