The world is not converging on one technology stack, and it probably never was.

In the 1840s, Britain's railways ran on a standard gauge of four feet eight and a half inches. But the Great Western Railway, designed by Isambard Kingdom Brunel, used a broad gauge of seven feet. Both networks grew rapidly. Both attracted investment and passengers. And when they finally met at interchange stations, passengers had to get off one train, walk across a platform, and board a different train on different tracks. Cargo had to be unloaded and reloaded. The gauge incompatibility was not a technical problem anyone failed to solve. It was a political and commercial choice that created two parallel systems, each internally coherent, each unable to interoperate with the other.

Something similar is happening in global technology right now, and the DeepSeek moment made it impossible to ignore.

The DeepSeek Signal

When DeepSeek demonstrated competitive AI capabilities built on different infrastructure assumptions, different training approaches, and different data foundations, the reaction in the Western technology press was a mixture of surprise and alarm. But the real significance was not that a Chinese lab had built something impressive. It was that the something impressive operated on entirely different foundations.

The assumption of convergence, the belief that the world would eventually run on one technology stack, was always more hope than observation. For two decades, it looked plausible. American cloud infrastructure dominated globally. Silicon Valley's product patterns became default worldwide. Google, Amazon, and Microsoft set the standards that everyone else built on.

But that era is ending, and it is ending not because of a single event but because of a slow accumulation of divergences that the DeepSeek moment crystallised.

The stack fracture is not coming. It is here.

Parallel Tracks

What does the stack fracture look like in practice? It looks like two (and increasingly more than two) complete technology stacks operating on different assumptions about data, identity, payments, regulation, and user expectations.

In one stack, cloud infrastructure runs on AWS, Azure, or Google Cloud. Identity verification uses Western standards. Payment rails connect through Stripe or traditional banking networks. Data residency follows GDPR or similar frameworks. AI models are trained on English-language data with Western content moderation norms.

In the parallel stack, cloud infrastructure runs on Alibaba Cloud or Huawei Cloud. Identity verification uses national ID systems with different privacy frameworks. Payment rails run through WeChat Pay or Alipay. Data residency follows Chinese cybersecurity law. AI models are trained on Mandarin-language data with different content filtering approaches.

These are not two versions of the same system. They are two different systems, built on different foundations, optimised for different contexts, and increasingly unable to interoperate cleanly.

The interoperability gap is growing, not shrinking.

At Grab, I learned this lesson at a smaller scale, and it shaped how I think about every "global" product claim I have encountered since. We built products that operated across multiple Southeast Asian markets. On paper, these were similar countries in the same region. In practice, every market was a different world.

Payment infrastructure varied wildly. In Singapore, credit cards were common. In Indonesia, bank transfers and cash-on-delivery dominated. In Vietnam, the regulatory environment for fintech was different from Thailand's, which was different from the Philippines'. User behaviours diverged in ways that no single product design could accommodate. The assumption that one product could serve all these markets with minor localisation was, to put it politely, optimistic. To put it accurately, it was wrong.

"Global" products are actually collections of local adaptations held together by a shared brand and a shared codebase. The adaptations are where the real work happens.

The Assumption of Convergence

The assumption of convergence has been the default mental model for technology strategists for most of the internet era. The logic seemed airtight. Networks benefit from interoperability. Standards tend to consolidate. The internet itself was proof that open, shared protocols would win.

But that logic was always conditional, and the conditions are changing. Networks benefit from interoperability when the political incentives favour openness. When they do not, networks fragment. The internet was proof of convergence only during a period when the major powers found convergence convenient. That period is over.

Product teams that assume a single global standard are building on ground that is already splitting.

I see this daily now. From Wayanad, I work with founders building products for both Indian and international markets. The infrastructure assumptions are already diverging, and these founders feel it in operational terms that no analyst report captures. Payment rails are different. India's UPI system processes billions of transactions on infrastructure that has no equivalent in the US or Europe. Identity verification works differently. India's Aadhaar system creates a foundation for digital identity that operates on completely different principles from Western approaches. Data residency requirements are becoming stricter, with India's own data localisation rules adding another set of constraints.

The fracture is not hypothetical for these founders. It is their daily operating reality.

But here is what makes this moment different from previous regional divergences. The AI layer is splitting too. When DeepSeek demonstrated that competitive AI could emerge from a different data environment, a different regulatory framework, and a different set of infrastructure dependencies, it signalled that the most important technology layer of this decade will not converge. It will fork.

What Product Teams Get Wrong

The most common mistake I see in product strategy today is treating the stack fracture as a future risk rather than a present reality. Teams plan for "global launch" as though global still means one product, one infrastructure, one set of assumptions. It does not.

But the second mistake is more subtle. Some teams respond to the fracture by deciding they will only build for one market. That sounds pragmatic. But it is also a bet that your chosen market will be the one that matters most in ten years, and that is a bet with far less certainty than it had five years ago.

The founders I work with who are getting this right are not choosing sides. They are building with the fracture in mind from the beginning. Modular infrastructure assumptions. Payment and identity layers that can be swapped. Data architectures that accommodate different residency requirements without requiring a complete rebuild.

It is not elegant. It is expensive and complicated. But it is honest about the world as it actually is, rather than the world that convergence promised.

The messy version is the accurate one.

The Tracks Are Laid

Brunel's broad gauge lasted until 1892, when Britain finally standardised. But standardisation only happened because one nation had the political authority to impose it. The global technology stack has no such authority. No single government can mandate that the world converge on one set of infrastructure standards, one set of data practices, one set of AI foundations.

The assumption of convergence was comforting. It simplified strategy, reduced complexity, and made "global" a meaningful product category. But comfort is not the same as accuracy.

The tracks are being laid in different gauges, and this time, there is no single authority that can order them torn up and relaid. Product teams will build for one world, or they will build for several. That choice, quiet as it seems today, will determine which products still travel freely a decade from now.