Your Platform's Biggest Risk Lives One Layer Down

Based on the research ofRainer Schmidt, Rainer Alt, and Alfred Zimmermann, "Towards a Theory of Multilevel Platform Ecosystems," International Conference on Information Systems (ICIS), 2025

The Stack Nobody Draws on the Strategy Whiteboard

Classical platform theory, from Rochet and Tirole onward, treats a platform as a single intermediary clearing transactions between two sides of a market. That model still describes plenty of businesses. It describes almost none of the interesting ones. Shopify is a platform to its merchants, but Shopify Payments runs on Stripe's processing infrastructure, and Shopify's own compute runs on Google Cloud. Apple's App Store is a platform to developers, but the App Store itself sits on top of iOS, which sits on top of Apple's silicon and services stack. X (formerly Twitter) was a platform to third-party clients like Tweetbot and Twitterrific, but those clients existed only because X's API let them. Every layer in these examples is simultaneously a platform to the layer above it and a complementor to the layer below it.

This is the gap that Rainer Schmidt, Rainer Alt, and Alfred Zimmermann target in "Towards a Theory of Multilevel Platform Ecosystems," presented at ICIS 2025. Their argument is that platform research has split into isolated streams, strategic orchestration at the macro level, governance mechanisms at the meso level, user interactions at the micro level, and that none of those streams, read alone, can explain where value and risk actually travel. Their fix is to model the pathways between levels as a multi-layer graph, and they ground the framework in the Amazon Alexa ecosystem, where skills built by third-party developers depend on Alexa's voice platform, which in turn depends on Amazon's device and cloud layers. Pull on any one thread and the others move.

The practical translation for executives: if you are building a product that depends on someone else's API, app store, cloud region, or payment rail, you are not just a participant in a market. You are a complementor nested inside someone else's governance structure, and that structure can be rewritten without your consent, your input, or even much notice.

When the Floor Moves: Three Verified Governance Shocks

The pattern is not hypothetical. It has happened repeatedly, in public, with documented consequences.

The clearest case is "Sherlocking", the practice, dating to Apple's 1990s Sherlock search tool, of a platform absorbing a complementor's feature into the core operating system. At WWDC 2024, Apple announced an iOS 18 call-recording and transcription feature, free and built into the dialer, that directly targeted the call-recording app TapeACall, whose subscription runs $79.99 a year. Apple also unveiled features overlapping with Grammarly, 1Password, Otter, and AllTrails. Philip Shoemaker, a former Apple executive who helped oversee the App Store, told NPR that if he were TapeACall, "I'd be saying game over." Rick VanMeter, executive director of the Coalition for App Fairness, which represents more than eighty developers including Spotify, Match Group, and Epic Games, put the structural point plainly: "Apple is not only a competitor, but it also sets the rules of the marketplace." BlueMail's maker, Blix, had already sued Apple over a related claim that "Sign in with Apple" copied its own feature, and was recruiting other sherlocked developers to join the fight. None of this is rivalry in the ordinary sense. TapeACall was not out-competed on quality or price by a peer; its market was reassigned by the operating system it runs on.

The second case shows the same dynamic through pricing rather than feature absorption. In 2018, Twitter announced it would retire its legacy APIs and replace them with a paid tier priced at $2,899 per month for 100 to 250 users, more than $11 per user, with anything larger required to negotiate enterprise pricing directly with Twitter. Tapbots' Paul Haddad and Iconfactory's Craig Hockenberry, makers of Tweetbot and Twitterrific respectively, told reporters the new terms would strip out timeline streaming and delay notifications by one to two minutes, materially degrading the product their users paid for. Hockenberry's verdict, given to MacStories at the time, proved prophetic: "Long term, I don't think there will be any apps other than the official one." Both apps were eventually forced out of the market. The complementors did nothing wrong. The platform they depended on simply decided the arrangement no longer served its interests.

The third case is less a conflict than an admission of exactly how deep the dependency runs. In a January 2023 announcement of an expanded partnership with Amazon, Stripe's own chief technology officer, David Singleton, said of Amazon Web Services: "We couldn't run without AWS, and we wouldn't want to." Stripe, itself a platform to millions of businesses, described AWS as providing "the core compute infrastructure on which Stripe is built." One layer down, Shopify's relationship with Google Cloud shows the same structure at even larger scale: during the 2025 Black Friday, Cyber Monday weekend, Shopify merchants generated $14.6 billion in sales, a 27 percent increase year over year, with Google Cloud absorbing 489 million requests per minute and 2.2 trillion edge requests. Shopify's VP of Infrastructure, Mattie Toia, called Google Cloud "the foundation for our entire platform." These are not failure cases, they are successful, voluntary dependencies, but they illustrate how completely a platform's operating reality is determined by the infrastructure layer it chose to build on, and how little room exists to simply swap that layer out once scale has been reached.

Why Two-Sided Market Thinking Undercounts the Risk

The Schmidt, Alt, and Zimmermann framework matters because it names something executives already sense but rarely formalize: governance does not stay contained within its own layer. Their second proposition is that meso-level governance structures function as "critical translation mechanisms", meaning the rules a platform sets for its complementors are themselves shaped by what the layer below demands of the platform, and those rules then propagate upward into what the complementor's own customers experience. When Apple tightens App Store commission policy, or AWS changes its pricing for a compute tier, the shock does not stop at the layer where it originated. It passes through every dependent layer until it reaches an end user who has no idea which infrastructure decision caused their favorite app to change, degrade, or disappear.

Their third proposition, that competitive advantage comes from multilevel alignment rather than single-level excellence, reframes what "defensibility" should mean for any company sitting inside someone else's stack. A complementor can have the best product at its own layer and still be erased by a decision two layers down, which means defensibility has to be evaluated across the stack, not just within the market the company believes it competes in.

"Apple is not only a competitor, but it also sets the rules of the marketplace."

Designing for the Stack You Are Actually In

The multilevel framework does not argue that building on top of other platforms is a mistake. Nearly every successful digital business of the last fifteen years has done exactly that, because the alternative, building every layer yourself, is slower and usually loses. What the framework corrects is the mental model executives use to price that decision. A platform team that benchmarks only its horizontal rivals, while treating its cloud provider, its app store, and its API partner as fixed and benign, is measuring half the risk.

The operational discipline this implies is straightforward even if it is rarely practiced: map every layer your product depends on, assign each one an explicit governance-risk rating based on how unilaterally that layer has changed terms in the past, and revisit that map on the same cadence you revisit competitive intelligence on peers. Amazon Alexa's skills ecosystem, TapeACall, Tweetbot, and Stripe's own candid admission about AWS are not edge cases. They are the normal condition of building inside a multilevel platform ecosystem, and the companies that treat that condition as a planning input, rather than a surprise, are the ones still standing when the layer beneath them moves.