The Companies profiting most from AI disruption are not the ones building AI products

The companies capturing the most value from the AI revolution are not the ones using AI to build remarkable new products. They are the ones selling the compute, the cloud, and the APIs that everyone else needs to build those products. Microsoft, Alphabet, and Amazon have remained resilient or grown during a period when application software companies are being repriced downward. The picks-and-shovels sellers are thriving. The miners are struggling.

This should not surprise anyone who has watched platform economics play out before. But it does, because every generation of technology builders convinces itself that this time the platform layer will stay neutral.

It never does.

The Colonisation Pattern

There is a pattern so consistent across technology markets that it deserves a name. I call it the colonisation pattern, and it works in three stages. First, a platform enables third-party builders by providing APIs, distribution, and infrastructure. Second, it observes which applications built on top of it gain traction and generate revenue. Third, it absorbs the most successful patterns into native platform capabilities, competing directly with the companies it enabled.

This is not conspiracy. It is incentive structure.

At Adobe, I watched the colonisation pattern from the inside. Creative Cloud was both a product and a platform. Third-party developers built plugins and extensions that extended Photoshop, Illustrator, and the rest of the suite. Some of these plugins were brilliant. They solved real problems that Adobe's core product team had not prioritised. Users loved them. Revenue flowed. But that revenue was a signal, not a reward.

But here is what happened next, and it happened with a reliability that you could set a calendar by. The product team would notice which plugins had the highest adoption. They would study the interaction patterns. And within eighteen to twenty-four months, a native version of that capability would appear in the next major release. The plugin developers who had built the market for that feature were suddenly competing with a free, integrated alternative that shipped pre-installed to every Creative Cloud subscriber.

The platform is never neutral. It is patient. And patience, at scale, is the most effective competitive strategy.

I do not say this with moral judgement. I was on the platform side. The logic was entirely rational. Why allow a third party to capture value from a use case that your platform made possible, when you could capture it yourself with zero customer acquisition cost? The answer, from inside the building, was obvious. You would not. But that obvious answer, applied systematically, creates a market dynamic that third-party developers rarely anticipate until they are already inside it.

The Other Side of the Table

At Freshworks, I experienced the colonisation pattern from the other side, and the view was considerably less comfortable.

We built products that depended on platform integrations. Salesforce, Google Workspace, Microsoft 365. These integrations were not optional features. They were the connective tissue that made our products useful in enterprise environments. A customer service tool that does not connect to email, calendar, and CRM is not a customer service tool. It is a standalone application that nobody will adopt.

But every integration was also a strategic vulnerability. Every time we built a deep connection to a platform, we were simultaneously making our product more valuable to customers and more visible to the platform owner. We were showing them exactly which workflows their users cared about, exactly which data connections generated the most activity, and exactly where value was being created on top of their infrastructure.

Every strategic decision at Freshworks was shaped by a question that nobody wanted to say out loud: what happens when the platform owner decides to build this themselves?

The answer was always the same. When Microsoft or Google decided to offer a native version of a capability we provided, they could reach every existing user at zero marginal distribution cost. We had to sell. They had to ship an update. But that is not a fair race. The competitive dynamics were not unfair in any legal sense. But they were structurally asymmetric in a way that no amount of product quality could overcome.

The Platform Paradox in the AI Era

What makes the current moment different is not that the colonisation pattern is new. It is that the AI era has accelerated the pattern and concentrated its effects.

The companies profiting most from AI disruption are the ones selling the infrastructure that makes disruption possible. Microsoft sells Azure compute and embeds Copilot across its application suite. Amazon sells AWS infrastructure and offers Bedrock for model deployment. Google sells cloud compute and integrates Gemini into Workspace. Each of them is simultaneously the infrastructure provider, the platform owner, and an application competitor.

This is the platform paradox: the platform profits from the disruption it enables, and then uses those profits to colonise the application layer that the disruption was supposed to create.

Application-layer companies building on these platforms face a version of the same dilemma I experienced at Freshworks, but with higher stakes and faster timelines. If you build an AI-powered application on Azure, your success is visible to Microsoft. If you build on AWS, Amazon sees your usage patterns. If you build on Google Cloud, Alphabet knows which workloads are growing. The infrastructure providers have perfect information about which application categories are worth entering.

They are not guessing about market demand. They are reading it directly from their billing data.

The Dependency Question

The standard advice for startups has always been to build on platforms, because that is where the distribution is. But the standard advice assumes that the platform will remain neutral long enough for you to build a defensible position. That assumption is becoming harder to justify.

I am not arguing that companies should avoid platform dependencies entirely. That is not practical. Almost every modern software product depends on cloud infrastructure, identity providers, and communication platforms that it does not control. The dependency is structural. You cannot opt out of it.

But you can be honest about what it means. Building on a platform is not a partnership. It is a tenancy. And the landlord is always watching the most successful tenants to decide which businesses to enter next. The platform paradox means that your growth, if it becomes visible enough, is the signal that triggers your competition.

The companies that survive the colonisation pattern do so not by avoiding platforms, but by building value that the platform cannot easily replicate. Proprietary data, deep domain expertise, workflow-specific integrations that are too niche for the platform to bother absorbing. But even specificity has limits when the platform decides to go broad. The defence is not scale. The defence is specificity, guarded by the knowledge that it is temporary.

Where the Value Settles

Every technology era has its version of this dynamic. The PC era concentrated value in the operating system layer. The mobile era concentrated it in the app store owners. The cloud era concentrated it in the infrastructure providers. The AI era is following the same script, with the same companies capturing the same structural position.

The application layer is where the innovation happens. But the platform layer is where the value collects. This has been true for decades, and no amount of disruption has changed it. The disruption changes what gets built. It does not change who profits.

There is something almost poetic about it. The most creative period in software development in a generation is producing enormous value, and most of that value is flowing downward, into the infrastructure layer, rather than staying with the builders who created it.

The platform was never neutral. It was always just waiting to see what worked.