Ch7 02: Your Competitor Doesn’t Need a Better Product — Just the Kill Switch Under Your Business#

Your competitor doesn’t need better marketing, better pricing, or a better team. They just need to own the thing your business stands on — and pull it away.

This is the kill shot most founders never see coming. They spend their time studying competitors who sell similar products, bracing for a head-to-head fight that may never happen. Meanwhile, the real threat sits quietly underneath: the platform, the API, the distribution channel, the data source their entire business depends on. When that foundation moves, the building doesn’t lean — it collapses.

Three Ways to Lose the Ground Under Your Feet#

The pattern repeats across industries and eras, following three distinct playbooks.

Cut the connection. You built your product on someone else’s API. You pull data from their system or distribute through their platform. One day they change the terms — rate limits, pricing, approval requirements — or revoke access entirely. Your product still works in theory. But it has no data to process, no users to reach, no pipeline to flow through. The pipe is shut. You’re dry.

This isn’t hypothetical. Twitter’s 2023 API pricing change killed hundreds of analytics and bot tools overnight. App Store algorithm updates have vaporized sellers’ organic visibility in a single cycle. The platform didn’t target them specifically. It optimized for its own interests, and theirs weren’t part of the equation.

Clone the feature. You built a successful tool extending a platform’s functionality. The platform notices your traction and builds the same feature natively. They don’t need to build it better — just build it at all. Their version is integrated, free, and default; yours is external, paid, and optional. Users don’t switch because the competitor is superior. They switch because switching costs drop to zero when the alternative lives inside the product they already use.

This is the “platform absorption” pattern. The platform lets a thousand flowers bloom, watches which attract bees, then plants its own version right next to yours — except theirs gets automatic sunlight and water. You built the proof of concept. They built the final product.

Change the rules. You operate under regulations, standards, or market norms that make your business viable. A larger player — often with lobbying power or market influence — pushes to change those rules in ways that benefit their model and handicap yours. New compliance requirements costing 30% of your revenue. New industry standards matching their architecture. New regulations creating barriers exactly where you need to pass.

Rule changes are the hardest to defend against because they feel legitimate. Nobody broke a contract. Nobody violated terms. The game just changed — in a direction that happens to favor the player with the most influence over its design.

The Dependency Audit#

If these threats are structural, the response must be structural too. You need a systematic way to identify, assess, and mitigate dependencies before they become fatal.

Step 1: List every external dependency. Walk through your entire operation — product, distribution, data, infrastructure, payments, compliance — and list every point where you depend on a third party. Be exhaustive. Include obvious ones (cloud hosting, payment processor) and non-obvious ones (the open-source library your product is built on, the industry certification customers require).

Step 2: Assess replacement cost. For each dependency, estimate the time, money, and effort to replace it. Some are easy: switching payment processors takes days. Others are effectively impossible: migrating off a cloud platform with two years of custom infrastructure could take six months and cost more than annual revenue.

Step 3: Mark the fatal dependencies. A dependency is fatal if: replacement cost is high (30+ days or 20%+ of runway) AND no viable alternative exists. These are your kill switches. Someone else holds them.

Step 4: Rate the likelihood. Not all fatal dependencies are equally dangerous. A cloud provider shutting you down is unlikely if you’re paying bills. A platform revoking API access because they’re launching a competing product — that has documented precedent. Focus mitigation on fatal dependencies with medium-to-high activation likelihood.

Four Strategies for Reducing Fatal Dependencies#

Once you’ve identified your kill switches, you have four options. None is free. All are cheaper than dying.

Build your own. Replace the external dependency with internal capability. Most expensive, most secure. If your business depends on a specific data source, can you build your own collection mechanism? If you depend on a distribution platform, can you build a direct customer channel? The cost is high, but the result is structural independence.

The trap: trying to build everything yourself. You can’t. The goal isn’t zero dependencies — it’s zero fatal dependencies. Build your own only for the ones that could kill you.

Diversify your sources. Instead of one platform, one supplier, one channel — distribute across multiple. If one cuts you off, others keep you alive. Portfolio approach to dependency management.

The key metric is concentration. If more than 50% of any critical input (traffic, revenue, data, distribution) comes from a single source, you’re concentrated. Below 30% from any single source is a reasonable target.

Route around. Redesign your business model to eliminate the dependency entirely. Not replacing the provider — removing the step. Can you change your model so the vulnerable step is no longer necessary? Go direct instead of through a distributor? Use a different technology that doesn’t require the same infrastructure?

This is the most creative option and often the most powerful. It forces rethinking your architecture from first principles.

Form alliances. If you can’t build, diversify, or route around, form a coalition with other businesses sharing the same dependency. Collective negotiating power beats individual. Platform providers are less likely to cut off a group representing 15% of their ecosystem than a single player at 0.1%.

Alliances are fragile and slow. But against a dominant platform, they’re sometimes the only viable option.

The Pitfalls of Dependency Thinking#

The false security of contracts. A three-year contract doesn’t protect you from price hikes at renewal, feature deprecation that erodes value, or the provider’s declining quality. A contract is a legal document, not a strategic guarantee.

The incrementalism trap. Dependencies grow gradually. One API integration. Then a second. Then custom features relying on platform-specific capabilities. Each step seems small. The cumulative effect is deep dependency — like a vine growing into a wall, easy to plant and nearly impossible to remove.

The time to worry about dependency is when making architectural decisions, not when it becomes a crisis. Every decision increasing reliance on a single external entity should trigger: “What happens if this goes away?”

The “they need us too” delusion. Founders rationalize dependencies by arguing the relationship is mutual — “We drive traffic to their platform, so they’d never cut us off.” Almost always wrong. The asymmetry between a platform and a single app is enormous. They lose a rounding error. You lose everything. Never assume symmetry in a structurally asymmetric relationship.

The 30-Day Test#

Here’s the exercise that should keep you up at night.

Take your dependency list. For each one, answer one question: If this dependency disappeared tomorrow — completely, no warning — how many days could your business continue to operate?

Be honest. Not “days until we find a workaround” — “days until the business stops functioning.” No revenue, no product, no service.

Any dependency giving you fewer than 30 days is a structural vulnerability. Fewer than 7 is an emergency. Zero days — business stops instantly — is a ticking bomb.

How many ticking bombs do you have?

Most founders doing this exercise for the first time discover more than expected. That’s the point. The exercise isn’t meant to comfort you. It’s meant to make you accurate.

You can’t eliminate all dependencies. Every business depends on electricity, the internet, the legal system. But you can identify the ones that are both fatal and controllable — where someone holds a switch that can shut you down, and you have realistic options to reduce exposure.

The founders who survive aren’t the ones with no dependencies. They’re the ones who know exactly where their dependencies are, how dangerous each one is, and what they’ll do when — not if — one goes sideways.

Know your floor. Know who built it. And have a plan for when they start pulling boards.