Your internal platform team exists to accelerate development. But what if their deliverables, meant to be assets, are actually functioning like illiquid stock? It's a shiny piece of paper with theoretical value that you can't actually spend, and it comes with a massive management burden.
A recent financial move brought this analogy into sharp focus. As TechCrunch reported, Elon Musk’s long-time backer Valor Equity Partners is distributing shares of SpaceX directly to its limited partners instead of cashing them out first. For the fund, it's a clean way to close the books. For the investors, it’s complicated. They get a valuable asset, sure, but one that’s not publicly traded. They now have to figure out the tax implications, find a buyer on a secondary market, and manage the holding. It's value, but it's also a new job.
This is exactly what happens in many organizations with their platform engineering strategy. The platform team builds a 'valuable' asset, like a shared component library or a set of Terraform modules, and distributes it to internal product teams. The roadmap item gets checked off. Velocity is declared. But the product teams, the LPs in this analogy, just inherited a new job they didn't ask for.
The Platform's In-Kind Distribution
When a platform team chooses to ship a library instead of a service, they are making an in-kind distribution. They are handing out stock, not cash. Cash is liquid. It’s an API call. It’s a managed service with an SLA. You use it, you get a predictable result, and you move on. An internal library is illiquid stock. It’s a bundle of code that a product team must now import, configure, and, most importantly, maintain.
Consider a common scenario: the shared UI component library. The platform team, let's call them Team Hydra, builds a beautiful, standardized VooButton component in React. It has all the approved brand colors, accessibility features, and analytics hooks. They publish it to a private NPM registry as @voostack/ui-kit version 1.0.0. They write some documentation and announce it in Slack. From their perspective, their work is done. They've empowered ten different product teams to build consistent UIs.
What really happens?
- Team Cerebus (Checkout Flow) pulls in
v1.0.0. They need the button to have a loading spinner, whichVooButtondoesn't support. They can either fork the component, creating a dreadedVooButtonWithSpinner, or file a ticket with Team Hydra and wait. - Team Phoenix (User Profile) is still on an older version of React because of a critical dependency.
@voostack/ui-kitrequires a newer version. They're blocked. - Team Minotaur (Marketing Pages) uses Next.js with the App Router.
VooButtonwas built with an older pattern and causes hydration errors when used in a Server Component. They spend a week debugging it.
Team Hydra didn't ship a solution. They shipped a problem with a nice API. They distributed an asset that requires active management from every single shareholder, multiplying the total cost of ownership across the entire organization.
The Hidden Taxes on Illiquid Tech Assets
Product teams are smart. They can handle this. But at what cost? Accepting this illiquid stock from the platform team comes with several hidden taxes that bleed their velocity dry.
The Maintenance Tax
This is the most obvious cost. Two months after the v1.0.0 release, a security vulnerability is found in a dependency of @voostack/ui-kit. Team Hydra patches it and releases v1.0.1. Who is responsible for updating the package in all ten product codebases? The product teams. Each team has to pull the update, run their tests, and deploy the change.
What was a single task for the platform team becomes ten separate tasks for the product teams. This tax is paid over and over. When React 19 is released, the library needs to be updated. When the analytics requirements change, the tracking hooks need to be modified. Each change by the platform team creates a cascading wave of unplanned work for everyone else.
The Integration Tax
No internal library is ever perfect for every use case. It's a lie we tell ourselves. The integration tax is the effort required to make the generic solution fit the specific problem. It's the wrappers, the shims, and the adapter code that every team has to write.
Let’s say the platform provides a Terraform module for provisioning a standard microservice. It's great, but it assumes you're using PostgreSQL. Team Phoenix needs to use Redis for caching. They now have to dig into the module's source code, figure out how to override the database configuration without breaking anything, and hope their changes don't conflict with the next upstream update. They just spent three days becoming experts in a tool they only wanted to use.
This tax is insidious because it looks like productive work. But it's friction. It's the cognitive overhead of learning and conforming to an abstraction that is 90% right, where that last 10% costs you a week of development time.
The Brittleness Tax
When you import a library, you import its entire dependency tree and its architectural opinions. Your application is now coupled to those choices. If the platform team built their Go CLI with Cobra and your team prefers urfave/cli, too bad. If their shared data models use a validation library you find clumsy, you're stuck with it.
This creates a brittle system. A change in a foundational, shared library can have unpredictable, far-reaching consequences. It discourages experimentation and locks large parts of the organization into a single way of doing things, even if that way becomes outdated. You wanted to accelerate teams, but you accidentally built a distributed monolith.
Pay in Cash: The Power of Managed Services
What's the alternative? Stop distributing illiquid stock. Start paying dividends in cash. In the world of internal platforms, cash is a managed service with a stable, well-defined API.
Instead of a @voostack/auth-logic library, the platform team should provide an internal authentication service. It lives at https://auth.internal.voostack.com. It has endpoints like /login, /refresh, and /userinfo. It has a clear SLA for uptime and latency.
The product team's responsibility is now drastically simplified:
- Make an HTTP request to the correct endpoint.
- Handle the response.
That's it. They don't know or care if the service is written in Rust, Go, or Node.js. They don't care if it uses PostgreSQL or DynamoDB. They don't have to manage its dependencies, patch its vulnerabilities, or scale its infrastructure. The platform team owns all of that.
This is a powerful shift in ownership and responsibility. The contract is no longer a chunk of versioned code; it's a network boundary with a formal API. The platform team can refactor, re-platform, and optimize the service continuously, and as long as they don't break the API contract, the ten product teams are completely unaffected. They are decoupled. They can move fast.
Building a true managed service is harder. It requires the platform team to think about operations, monitoring, and on-call rotations. It is a much bigger investment than just publishing a package. But it’s an investment that pays real dividends in developer productivity, rather than just shifting costs around the org chart.
Is Your Platform Creating Debt or Dividends?
How can you, as a technology leader, diagnose whether your internal developer platform is shipping assets or liabilities? Ask yourself these questions:
- How is 'done' defined? Is a platform project 'done' when the code is published, or when a consuming product team has successfully integrated it and is meeting their own goals?
- Where does the maintenance burden fall? When a foundational framework (like Next.js or Spring Boot) has a major update, does one platform team handle the migration, or does it trigger a six-month, company-wide coordination effort?
- What does support look like? Does the platform team offer an SLA for their service, or do they offer 'office hours' for their library?
- How are teams measured? Is the platform team measured on packages published and features shipped, or are they measured on the velocity and autonomy of the product teams they serve?
If your answers lean towards the former in each case, you might be running an internal VC fund that specializes in illiquid distributions. You're creating the illusion of progress while actually saddling your most valuable teams with hidden technical debt.
What this means for your team
- Audit your internal 'products'. Categorize them. Is this a library that pushes ownership downstream, or a service that abstracts it away? Be honest about the total cost of ownership.
- Shift platform incentives. Your platform team's primary customer is your internal developer. Their goal should be to reduce cognitive load for product teams, not just to ship code.
- Invest in APIs, not just packages. Favor building robust, managed services over creating shared libraries wherever a clear service boundary can be drawn.
- When you must ship a library, treat it like a real product. It needs a dedicated owner, a clear support model, and a budget for maintenance and migrations. Don't just throw it over the wall.
Transforming your platform from a library distributor to a managed service provider is not easy. It's a fundamental change in mindset and a significant technical investment. But it’s the only way to stop handing out illiquid stock and start paying the kind of dividends that truly accelerate your business: fast, focused, and autonomous product teams.
Building something in this space? AgileStack helps teams ship enterprise-grade software without the consulting-firm overhead. Book a 30-minute call and tell us what you're working on.