What Makes a "Platform"? A Measurable Definition Nobody's Using

The Definition

A product becomes a platform when the things built on top of it by people outside your company eclipse what your own team builds.

Not just API traffic (though that's a useful leading indicator). The real shift is when outside developers, agencies, consultants, and increasingly AI agents are building more on your infrastructure than your own engineers are. When partners can build services businesses on top of your product. When the ecosystem around you grows faster than you do.

That means providing the systems, documentation, and support infrastructure to make that possible. It means being the kind of foundation that other people bet their livelihoods on.

If the majority of what happens inside your product is initiated by someone else's code, you're well on your way. If it's mostly humans clicking around in your UI, you're a product. (A good product, maybe! But a product.)

Before I defend this, let me lay out what the smartest people in tech have already said about the word. Because there's been no shortage of attempts.

The Existing Definitions

Bill Gates: The Economic Value Test

The most famous definition comes from a story Chamath Palihapitiya tells about Facebook's early days. When Facebook raised money from Bill Gates shortly after launching "Facebook Platform," Gates reportedly told them:

"That's a crock of shit. This isn't a platform. A platform is when the economic value of everybody that uses it exceeds the value of the company that creates it."

Windows was his proof. Microsoft captured a minority of the total value of the Windows ecosystem. The billions in value created by every company building Windows software dwarfed Microsoft's own revenue.

It's a great definition, and honestly it's the one I keep circling back to. The problem is that you can only really confirm it after it's already happened. But as a north star? "Their revenue will exceed yours" is a pretty clarifying frame. It changes how you think about everything you build.

Ben Thompson: Platforms vs. Aggregators

Ben Thompson at Stratechery drew a sharper line. His framework:

• Platforms facilitate a relationship between third-party suppliers and end users
• Aggregators intermediate and control that relationship

By this logic, Google and Facebook aren't platforms at all. They're aggregators. They don't empower third parties to build independent businesses; they sit between suppliers and consumers, controlling the relationship.

This is useful for understanding power dynamics, but it doesn't give you a way to measure whether you've crossed a threshold. It's more of a taxonomy than a test.

Scott Brinker: The App Creation Test

Scott Brinker (former VP Platform Ecosystem at HubSpot, editor of chiefmartec) offered something more operational:

"A platform feeds the creation of more apps than it absorbs through consolidation."

This is closer to measurable. If more apps are being built on top of you than you're acquiring or replicating, you're a platform. It captures the idea that platforms grow their ecosystem rather than cannibalizing it.

But it's also hard to measure cleanly. How do you count "apps absorbed through consolidation" vs. natural product evolution? And plenty of companies with healthy partner ecosystems would fail this test during an acquisition spree.

Sangeet Paul Choudary (Platform Revolution): The Interaction Model

Choudary, Parker, and Van Alstyne define a platform as:

"A business based on enabling value-creating interaction between external producers and consumers."

This is the academic gold standard. Their framework emphasizes the shift from "pipeline" businesses (linear value chains) to platform businesses (multi-sided networks). The platform's job is to facilitate interactions, not produce the product itself.

It's conceptually clean, but again, it's hard to draw a bright line. When does a product with a partner ecosystem become a platform? When you have 10 partners? 100? When their combined revenue exceeds yours? We're back to Gates territory.

Evan Bottcher (ThoughtWorks): The Self-Service Test

Evan Bottcher gave us a definition that's especially popular in engineering circles:

"A foundation of self-service APIs, tools, services, knowledge, and support which are arranged as a compelling internal product."

This one's interesting because it includes internal platforms. Your DevOps team might build a platform for your engineering org. But it also captures something important: self-service. A platform should be usable without asking permission or filing a ticket.

Jeff Bezos: The API Mandate

And then there's Bezos, who in ~2002 issued his famous mandate to all Amazon teams:

1. All teams will expose their data and functionality through service interfaces.
2. Teams must communicate with each other through these interfaces.
3. All service interfaces must be designed to be externalizable.
4. Anyone who doesn't do this will be fired.

He didn't define "platform" explicitly, but he described how you build one. The result was AWS, which is perhaps the purest example of a product-to-platform transition in history. Amazon built internal tools, exposed them as APIs, and eventually more usage came from external developers than from Amazon itself.

(Sound familiar?)

So Where Does the 50% API Rule Fit?

Here's what I think is interesting about all these definitions: they're mostly qualitative. They describe what a platform feels like, what it does, how it's structured. But they don't give you a number you can track.

If you want a leading indicator (something you can actually watch in real time), here's a useful one: track when more than 50% of your product usage comes from external API calls. Not internal microservices talking to each other. Not your own mobile app hitting your own backend. External parties. Other companies' code.

It's not the definition of being a platform (the real test is the ecosystem one above), but it's a pretty reliable signal that you're getting there.

Here's why I think it's useful:

It captures the Gates insight without waiting for it. If more than half your usage comes from external API calls, external parties are almost certainly creating more value on your platform than you are internally. You don't need to estimate total economic value; you can just look at your API logs.

It aligns with the Brinker test. If external developers are driving the majority of your product usage, they're almost certainly building apps and workflows on top of you. The "app creation vs. absorption" dynamic is a natural consequence.

It's Bezos-compatible. Amazon's internal API mandate was the precondition for platform status. But the moment Amazon became a platform was when external usage overtook internal usage. The mandate was the how; the 50% line is one way to see the when.

It distinguishes between "product with an API" and "platform." Lots of products have APIs. Most of them are used for basic integrations (syncing contacts, triggering webhooks). That's not a platform. A platform is when the API becomes the primary way your product gets used, by people who don't work for you.

Where It Gets Tricky

I'm not going to pretend this definition is bulletproof. There are edge cases.

Consumer social platforms. Facebook, Instagram, TikTok. These are clearly "platforms" in the colloquial sense, but most usage is humans scrolling through a UI, not API calls. Then again, Thompson would argue these are aggregators, not platforms. The 50% rule might actually be drawing the right line here, just differently than people expect.

Marketplaces like Uber and Airbnb. Users interact through the app, not through APIs. But the supply side is entirely external. The 50% rule doesn't capture this cleanly because the usage metric (rides, bookings) isn't primarily API-driven, even though the business is clearly a platform. (Though I'd argue that internally, a huge percentage of Uber's system activity is API-driven, between driver apps, payment processors, mapping services, etc.)

Internal platforms. Bottcher's definition covers internal platforms, and they're real and important. But they're a different animal. When your DevOps team builds a platform for your product engineers, that's great infrastructure. It's not the same strategic conversation as "Salesforce's partner ecosystem earns 6x what Salesforce does." Internal platforms optimize your own team's efficiency. External platforms create economic gravity that pulls other businesses into your orbit. Both are worth building; they just aren't the same thing.

The threshold itself. Why 50%? Honestly, the exact number matters less than the direction. The point is to have something you can actually track over time. If you're at 5% external API usage, you've got work to do. If you're at 40%, you're on the cusp. 50% is a useful Schelling point, not a magic line.

The Real-World Test

Let's run a few examples through this:

Salesforce: 90% of customers use AppExchange apps. Every one of those apps makes API calls. For every $1 Salesforce earns, its partner ecosystem earns $6.19. The majority of API traffic in most Salesforce orgs comes from third-party integrations. Verdict: Platform. ✓

Shopify: 80%+ of merchants use third-party apps, with an average of 6 apps per store. Shopify itself makes ~34 of the 16,000+ apps in their store. Individual third-party apps can consume up to 70% of a store's API limit. Verdict: Platform. ✓

HubSpot: 1,500+ marketplace integrations, average customer installs 7 apps, partner ecosystem projected at $12.5B in revenue. They don't publish their internal-vs-external API traffic split, but with 7 third-party apps per customer each making API calls, the math gets compelling fast. Verdict: Platform. ✓ They hired Scott Brinker to build the ecosystem, and he did.

Stripe: Almost 100% of usage is API-driven, and a massive ecosystem of SaaS companies builds on top of it. Verdict: Platform, but not from day one. It was born API-first, which is a great foundation. But being API-first doesn't make you a platform any more than having a parking lot makes you a mall. Stripe became a platform when Connect launched, when thousands of SaaS companies embedded it as infrastructure, when agencies started building entire practices around Stripe integrations. The API was the precondition; the ecosystem was the platform.

A typical B2B SaaS tool with a REST API: Has an API. A few customers use it for integrations. 95%+ of usage is people clicking buttons. Verdict: Product. A good product! But not a platform.

What Changes When You Cross the Line

This isn't just semantic navel-gazing. Knowing whether you're a platform or a product changes how you invest, what you build, and maybe more importantly, what you stop building.

Your incentives shift. When you're a product, you optimize for feature completeness. When you're a platform, you optimize for partner success. That doesn't mean you stop building (please don't stop building). It means you can make better strategic bets because you don't have to build everything. Your ecosystem fills in the gaps you'd never get to: the long-tail use cases, the industry-specific workflows, the weird integrations that three customers need desperately but would never justify your engineering team's time.

The companies that get this right end up building more ambitiously, not less. They focus their engineering on the hard platform primitives that nobody else can build, and they let the ecosystem handle the rest. That's not abdication. That's leverage.

You need to support an ecosystem, not just expose an API. Being a platform means agencies and consultants can build services businesses on top of your product. It means independent developers (and increasingly, AI agents) can create real value without asking your team for help. That requires documentation, tooling, sandbox environments, partner programs, and a genuine commitment to not pulling the rug out from under the people who bet on you.

If you're a product trying to get there, track your external API call volume. Segment it by source: your code vs. everyone else's. Watch the ratio over time. When external usage starts climbing toward 50%, you're making the transition.

If you're already a platform, the ratio tells you something about health. Is your ecosystem growing? Are third-party developers building more, or less? Is your API traffic diversified across many partners, or concentrated in a few? These are leading indicators of platform durability.

If you're an integration company (hi, that's us), this framework helps you spot which of our clients' products are ready for a platform strategy and which ones aren't there yet. A product with 5% external API usage needs better integrations. A product with 40% is on the cusp of something much bigger.

The Definitions, Ranked

Here's my totally subjective ranking of platform definitions, from most to least useful for making actual decisions:

So, What

Every company wants to be a platform. The word sounds impressive in pitch decks and earnings calls. But most companies calling themselves platforms are really products with APIs.

That's not a criticism. Products are great. But if you want to know whether you've actually made the transition, stop looking at your partner count or your marketplace listings or your developer conference attendance.

Ask yourself: are outside companies building more on top of your product than your own team is? Can agencies build real businesses around your ecosystem? Could an AI agent do something useful with your APIs without a human hand-holding it through the process?

If yes, congratulations. You're a platform.

If not, look at your API logs. Track the ratio of external to internal usage. Watch it over time. When it starts climbing, you're on the right path.

And either way, you've got work to do. At least now you know what you're aiming for.

---

At Left Hook, we help companies build and scale their integration ecosystems. Whether you're a product trying to become a platform, or a platform trying to grow your third-party API traffic, we've been in these conversations for 12+ years.