The Complement Trap in Platforms

Platforms thrive when the things around them get better: payments make a marketplace usable, identity makes a SaaS deployable, and games make a console worth buying. The hard part of building platforms isn’t the core, it’s managing the complements. They set adoption, pricing power, and who captures value.

Complements expand demand for the core, but they also re-route value. If you mismanage that flow, you fall into what we call the complement trap. Either you become dependent on a scarce, strategic complement that later “holds you up,” or you over tax your own complementors (or allow double markups) and quietly throttle ecosystem growth. The craft is knowing when to build, buy, subsidize, or standardize so the total pie grows, and your share stays durable.

How value really flows

Think of the bundle a customer actually buys: core + complements. The buyer’s willingness to pay (WTP) covers both. Every pound the complement captures is a pound the core can’t capture, unless the bundle creates enough surplus for everyone. When complements get scarce or over-monetized, the all-in price drifts above WTP and adoption stalls. When complements are abundant but chaotic, switching costs and uncertainty become the hidden tax.

Three ways teams building platforms get trapped

Partner hold-up where one complement becomes the gateway to usage, an identity provider, a last-mile carrier, a specialized data feed. As your dependence grows, their bargaining power increases. And with it, prices can rise, quality may deteriorate and roadmaps can be hijacked. There are a few practical measures you can take. For instance, you can multi-home so a single vendor can’t switch off your growth. You can also sponsor an open standard to make suppliers more substitutable. Last but not least, if the complement is both high importance and truly scarce, you must consider internalizing it by building or acquiring the capability, then keep the interface open so you don’t become the bottleneck you feared.

Double marginalization is a harder problem. As a reminder for readers, double marginalization is the economic problem occurring in a vertical supply chain when both an upstream and a downstream firm have monopoly power resulting in a higher final price for consumers. This “double markup” creates inefficiencies, leading to suboptimal outcomes that an integrated firm could avoid. A common scenario is: the core adds a markup, the complement adds another. The bundle’s effective price overshoots WTP, even though each piece looked reasonable in isolation. Integration lets you set a single price that maximizes adoption. Alternatively, instead of owning it, you can mimic the effect with bundles, two-part tariffs (light base + usage where value scales), revenue share caps, or cost-plus mandates for essential complements.

Finally, ecosystem taxation happens when you are the problem. High take rates, volatile rules, or policy friction make partners de-invest. In this case variety shrinks and innovation slows. Users feel it as fewer choices and more lock-in. The fix for this problem is simply governance, keep your policies stable and transparent, use progressive take rates (lower for new or essential categories). You can also issue credits or capability subsidies where scarcity is impacting growth and publish incident reports and roadmaps so partners can plan with you, not around you.

Three examples where this dynamic plays out

Next, we are going to see three real life examples of how this dynamic plays out. Then in the following sections we’ll discuss the strategies to address the tolls and how they apply concretely to our examples.

1) Managed Firewall / MDR + Threat-Intel & Sandbox

In a managed security service, analysts need timely context to decide whether an alert is benign or malicious. Two complements do a lot of the heavy lifting here: threat-intelligence feeds that enrich indicators with reputation and behavior, and malware sandbox detonation/analysis that executes suspicious files to observe behavior and extract IOCs. These aren’t nice-to-have add-ons; without them, detections are noisier, investigations take longer, and customer trust erodes.

The trap shows up in three predictable ways. First, over-dependency: when the service relies on a single premium feed or a single sandbox provider, that supplier gains leverage. A price rise, degraded support, or a breaking API change could immediately slow investigations and pushes backlog up, yet you have little room to maneuver. Second, double pricing: the feed vendor charges per event or per lookup, the sandbox charges per detonation minute, and your managed service charges per device (or per alert in some incident response retainer models). Each price looks reasonable on its own, but together the all-in cost exceeds what customers are willing to pay, so they reduce log volume, disable sandboxing, or downgrade tiers, creating blind spots that erode outcomes and renewals. Third, ecosystem taxation: if you insist on a proprietary “house” feed and make it difficult for customers to bring preferred sources, partners stop integrating, the catalog of complements shrinks, and the service looks closed and inflexible.

2) IP Transit + DDoS Scrubbing

Another example could be a customer solution that combines IP Transit with DDoS scrubbing. You need IP transit to carry packets to and from the public internet, and you need upstream scrubbing to filter volumetric floods before they saturate links or overwhelm apps. The two are complementary, without scrubbing, attacks fill your pipes and without stable transit, the “clean” traffic has nowhere reliable to go.

Here buying them as separate products often creates stacked tolls: a transit commit (with overage) plus scrubbing that’s metered per clean-Gbps or per mitigation event. Quiet months look fine. However, during sustained attack seasons, bills spike unpredictably and customers start cutting features or shopping around. There’s also dependency risk. If you rely on a single scrubbing partner or region, a service incident, capacity shortfall, or sudden price change immediately hits availability and cost. On-demand (cold) activation adds delay at the worst moment.

3) AI Retrieval Stack: Embeddings, Vector Store, and Inference

The last example could be a customer solution that leverages Retrieval-Augmented Generation (RAG). In this case, you need an embedding model to project document chunks into a high-dimensional space, a vector store to perform approximate-nearest neighbor similarity search (often with metadata filters and optional re-ranking), and a generation model to compose the final answer from the retrieved context. All stages are interdependent and complementary; for this design, removing any one of them breaks the intended behavior.

Here’s a likely trap. Early on, teams pick one embedding API and one hosted vector store because it’s the fastest way to launch. Later, the embedding provider changes models or pricing. Since your entire “map” was drawn with their alphabet, you may need to re-embed the whole corpus and rebuild indexes. This is a costly, time-consuming effort with little room to mix old and new spaces. Meanwhile, both the vector layer and the generation model meter usage, and cloud data-movement adds egress fees. You can see that together those tolls can push all-in unit costs beyond what customers will accept at scale.

A simple way to choose your move

Most complement decisions can be reduced to two variables: the importance to your growth and the scarcity in supply. That gives you a clear rulebook:

• High importance | high scarcity. Own the chokepoint if you can, build or acquire, but set open interfaces so others can still innovate, and price moderately to maximize bundle adoption rather than tolls.
• High importance | low scarcity. Your job is coordination, not production. Standardize APIs and data contracts, curate quality, and stay neutral so suppliers keep investing. Don’t crowd out partners with a “house” version unless you genuinely reduce friction.
• Low importance | high scarcity. Avoid owning. Subsidize or co-develop to relieve the squeeze (tooling, credits, guarantees), then step back.
• Low importance | low scarcity. Let the market work. Over-governing commoditized complements is how you manufacture your own tax.

There are two practical proxies that make the above measurable. For scarcity, compute a simple concentration metric on your routed usage, in this case the Herfindahl–Hirschman Index (HHI). You’ll learn quickly whether a few suppliers dominate or the field is genuinely competitive.

For switching friction, there are two tests. The break-even (can the savings from switching pay back migration within 3–6 months?) will help you decide if switching costs are low/bounded (this is good) or material (this is a warning). The other test is the quarter test (can you dual-run and cut over within a single roadmap quarter?). This test will help you judge practical switching friction (runbooks, tokens, data formats, contracts, etc). If these two tests fail. This is certainly not low scarcity. Therefore, you should consider building / acquiring the complement or alternatively secure long-term terms and keep interfaces open while also pricing moderately.

A quick check for hidden tolls

If you like one good number, track a Complement Tax Index (CTI) across your big categories. Think of it as attach rate x markup x usage share, summed across complements. If CTI rises faster than WTP or coincides with falling attach rates and longer time-to-first-value, then you’re taxing growth. The remedy is straightforward: cap markups, bundle essentials to eliminate double pricing, or add substitutes to relieve pressure.

How these strategies apply to the three examples

Scarcity differs across the examples discussed. We apply the same rulebook, but the move changes: where supply is abundant, standardize and stay neutral. While where chokepoints exist, integrate or secure capacity and price gently.

Managed Firewall / MDR + Threat-Intel Feeds & Sandbox Analysis

Importance is high, the quality and speed of investigations depend on them. At the same time scarcity is usually low to moderate because multiple credible providers exist. That points to standardize, curate, and stay neutral. We should only consider owning if concentration or lock-ins make the quarter/payback tests fail.

Concretely, treat feeds and sandboxes as interchangeable components rather than one-way dependencies. Design your TI enrichment and sandboxing as pluggable services behind an internal contract that you can swap, mix, or fail over without rewiring detections or playbooks. Standardize ingestion and verdict formats, keep several suppliers certified and ready, bundle a sensible default, and make bring-your-own straightforward. Additionally, operate so that a source can be swapped in days, not months. On pricing, include light baseline enrichment in the core offer, then meter where value scales, with clear caps so strong security months don’t become punitive bills. Sanity-check the posture with the two tests described previously. Can you swap or dual-run a provider within one quarter, and does the move pay back in 3–6 months? If either fails, scarcity is higher than you think. So, you need to lower friction or consider securing a strategic feed.

IP Transit + DDoS Scrubbing

In this scenario importance is high with moderate–high scarcity (often metro/seasonal). We need to look at building or tightly integrating protection where feasible while keeping open interfaces so specialist needs can still use alternates.

Here you need to engineer for multi-homed mitigation so traffic can route through more than one partner. Also, it’s recommendable to replace penalty-style overages with burst credits to keep the all-in price predictable. Price gently on the included layer to lift adoption of the bundle. Then recover margins on predictable commitments (e.g. capacity) rather than bad-day spikes. Apply the tests: stand up a second provider and shift meaningful traffic within one quarter, with 3–6 month payback. If not possible, then treat this as a chokepoint and secure capacity early.

AI Retrieval Stack: Embeddings, Vector Store, and Inference

In the last example importance is high across the stack while scarcity varies. Inference capacity can be scarce during surges, while vector databases are usually abundant. That mix points to own/secure the scarce bits, and standardize and stay neutral where there is enough supply.

You can summarize the approach as own the contracts, not the vendors. Keep the original documents and the “chunking” recipe in your own storage so re-embedding is a routine job. Maintain an adapter layer that lets you run at least one open embedding model alongside any commercial option. Also design your retrieval so you can dual-run the old and new maps during a migration. Treat the vector database as replaceable plumbing by using portable formats and standard query patterns, regardless of it’s a managed service or something you host. For the generation step, route requests across more than one provider so you can pick the version that meets your quality-and-speed target at the best unit cost. On pricing, avoid stacking percentage fees at each step. Give preference to a small platform fee plus clear, metered usage and caps that prevent good months from turning punitive invoices.

Then run the tests: can you dual-run and cut over the embedding/vector combination within one quarter? And does the unit-economics improvement pay back in 3–6 months? If not, you’re exposed to a chokepoint. Therefore, secure alternatives or capacity accordingly.

Pricing and governance that compound, not constrain

All in all, healthy platforms price for adoption first, extraction later. That usually means low entry tolls and metering where value scales. It also means avoiding punitive overages that turn success into a penalty. It makes sense to use burst credits and grace bands so customers don’t fear usage. In the governance area, publish versioned contracts, predictable deprecation policies, and fair access rules. The most precious resource in an ecosystem isn’t capital, it’s partner confidence.

In summary

Start by mapping your complement landscape on the importance x scarcity grid. Compute HHI on the usage you route (not the analyst market share). Then pressure-test switching with:

- The break-even test (can savings repay migration in 3–6 months?)

- The quarter tests (can you dual-run and cutover in less than 12 weeks?)

As general rule you should be tracking the Complement Tax Index (CTI) over time. If it climbs while attach rates fall, act. Decide, explicitly, for each category: build, standardize, subsidize, or leave alone, and document why.

Additionally publish the contracts that make switching easy (APIs, schemas, portability, SLAs, versioning and deprecation). Align pricing with adoption: gentle on the on-ramp, metered where value scales. Finally, measure ecosystem vitality the way customers feel it: time-to-first-value, net-new SKUs or apps per quarter, partner NPS, payout share and attach rates.

The bottom line is complements can be your growth engine or your toll road to stagnation. Own the true chokepoints to kill hold-up and double markups, keep interfaces open so variety compounds, and price with a light touch so the ecosystem and your defensive moat grow together.