The Fragility Fault-Line

The House of Cards

19Primary in The 198

31.3%Named factor across all 198

4.0Avg overall failure score

The pattern

The business was not brought down by a shock. It was brought down by a dependency — a single customer, supplier, partner, platform, regulator, or capital source that had become structurally irreplaceable, without redundancy, without a plan, and often without acknowledgement that the dependency existed at all. When that thing failed, the business had nothing to stand on.

DZ7 is not about bad luck. All businesses have dependencies. The distinction is between dependencies that are managed — diversified, hedged, or deliberately accepted with eyes open — and dependencies that are structurally irreplaceable and unaddressed. The Fragility Fault-Line is the one that was known and not mitigated. Score it on the degree of known, unmitigated concentration. Not on the fact that something broke.

The human signal in DZ7 is specific: the dependency was visible; someone chose not to address it. In Barings Bank, internal audit identified that Nick Leeson controlled both trading and settlement simultaneously — and the finding was filed rather than acted on. In Phones4U, the network operator dependency was the entire business model — visible, unmitigated, and terminal the moment EE and Vodafone made independent decisions about direct sales. The knowledge preceded the collapse. The action didn't.

The signal you are probably not looking at

What single thing, if it went away tomorrow, would make your business unviable within 90 days? One customer that represents more than 30% of revenue. One supplier with no credible alternative. One platform whose API terms you depend on. One regulatory approval that hasn't been stress-tested. Name it. Now ask: what is the plan if it goes? If the answer is "we'd figure it out," you have a fault-line. If the answer is a specific, costed, executable plan — you have a managed dependency. The difference is not the dependency itself. It is whether you have looked at it honestly.

You are approaching this zone

The businesses that survived DZ7 did so by addressing the dependency before it was triggered. Both paths are documented below.

Businesses that didn't act — and what it cost them

Barings Bank Finance · UK · Bankruptcy 1995 · Age 233 Did not act

Signal visible 1992: internal audit identified Nick Leeson controlled both trading operations and back-office settlement simultaneously in Singapore — the finding was noted and not remediated

The structural fault that destroyed Barings Bank in 1995 was identified by the bank's own internal audit three years before the collapse. Nick Leeson's simultaneous control of trading and settlement in Singapore was a textbook control failure — the single point of oversight that made concealment possible. The audit finding was filed. The control separation was not implemented. Leeson used the gap to conceal £827M in losses in account 88888 over two and a half years.

When the losses became unmovable in February 1995, the 233-year-old bank had no capital to absorb them. The Bank of England's post-collapse investigation confirmed that the control failure — not the complexity of the derivatives, not the market conditions — was the proximate cause. The dependency was a single person in a single role with unremediated dual control. The knowledge that this was dangerous existed. The action didn't.

What the dependency looked like from inside

Leeson was profitable, praised, and promoted. The audit finding about his dual role sat in a file. Raising it would have meant disrupting a star trader and requiring management attention to a Singapore operation that was generating exceptional returns. The cost of remediation appeared higher than the cost of deferral — until the cost of deferral became the collapse of an institution.

Phones4U Retail/Telecoms · UK · Shutdown 2014 · Age 20 Did not act

Signal visible 2012: O2 had already withdrawn its contract — a direct signal that network operator decisions could make the entire business unviable overnight, with no structural mitigation in place

Phones4U's entire business model was dependent on three network operators — EE, Vodafone, and O2 — choosing to sell their contracts through independent retailers rather than their own stores. When O2 withdrew in 2012, the signal was direct and documented: the dependency was real, and network operators were actively building direct sales capability. No structural response was made to diversify the dependency or build a business model less reliant on contract renewals that the operators controlled entirely.

In September 2014, EE and then Vodafone refused to renew their contracts. The business had zero revenue within 24 hours. The 5,500 employees who lost their jobs, the suppliers who lost their receivables, and the £200M in PE debt that evaporated — all were consequences of a dependency that had been visible, unmitigated, and fatal. The collapse took a day. The fault-line had been building for years.

What the dependency looked like from inside

The network contracts were the business. Building a model less dependent on them would have meant building a different business — one that competed with the operators in some dimension rather than distributing for them. That strategic conversation required acknowledging that the current model was fragile. The PE ownership structure, optimised for exit rather than resilience, had no incentive to make that trade.

A business that addressed the fault-line before it broke

Spotify Music Technology · Sweden · Founded 2006 · Still trading Acted

Signal visible 2015–2018: three major labels controlled licensing that could be withdrawn, repriced, or restructured at any time — an existential single-vector dependency that Spotify was actively working to reduce

Spotify's business, from its founding, ran on licensing agreements with the major labels — Universal, Sony, and Warner — that were renegotiated periodically, whose terms were opaque, and whose renewal was never guaranteed. The labels were simultaneously suppliers, competitors (through their own streaming initiatives), and the single point of failure that could make Spotify's entire library unavailable. The dependency was structural, known, and actively discussed in every investor conversation.

Rather than accepting the dependency as permanent, Spotify invested over years in three structural responses: direct licensing deals with independent artists and smaller labels to reduce major label leverage; original podcast content to create programming not dependent on music licenses; and an algorithmic discovery layer — Discover Weekly, Daily Mix — that created user value independent of any specific licensed track. None of these eliminated the label dependency. All of them reduced it, diversified it, and gave Spotify negotiating leverage it wouldn't otherwise have had.

What they did differently

They treated the label dependency as a known structural risk requiring active management — not as an unchangeable business condition to be accepted. The investments in podcasting, direct artist relationships, and algorithmic value creation were all, at their root, dependency-reduction strategies. They didn't wait for a label to withdraw to discover how fragile the single-vector structure was. They built structural redundancy while the business was growing and the labels had no reason to act against them.

What the survivors had in common

Businesses that navigated DZ7 didn't eliminate their dependencies. They managed them. Three things consistently separated those that survived from those that didn't.

They named the dependency precisely — as a risk, not a feature

Every business in DZ7 had a dominant dependency. The businesses that failed typically described it as a feature of their model — "we're the leading network retailer," "we're the exclusive distribution partner." The businesses that survived described it as a risk — "we are entirely dependent on three operators' contract decisions; here is our plan for each scenario." The reframe from feature to risk is not semantic. It changes who is responsible, what is measured, and what gets invested in. You cannot manage a dependency you have not formally named as one.

They invested in redundancy before they needed it

The window for building structural redundancy is when the primary dependency is intact and the business is generating cash. That is also the window when redundancy investment appears unnecessary — the dependency is working, so why spend resources on an alternative? The businesses that survived made that investment anyway: a second supplier qualified before the first failed, a second revenue stream developed before the first was threatened, a second customer segment cultivated before the first showed signs of churning. The investment is always more expensive in hindsight than it would have been in advance.

They stress-tested the dependency explicitly — and planned for its failure

The specific exercise that separates DZ7 survivors is the honest answer to one question: what happens to the business if this dependency fails tomorrow? Not what the business would try to do — what would actually happen, given current capital, current team, current customer relationships. The businesses that failed had not run this calculation or had run it and suppressed the answer. The ones that survived ran it honestly, didn't like the answer, and took action before the scenario became real. The stress test is not the plan. It is the forcing function that makes the plan necessary.

The dependency was visible. The fault-line was documented. The businesses that survived chose to address it. The ones in this database chose to defer it — until deferral became impossible and the cost had compounded beyond recovery.

Business 199 is always optional

The interrogator identified this architecture. What it cannot do is stress-test your specific dependency.

That requires someone who can map your actual dependency structure — not the version in the investor deck but the operational reality — and work through what happens to the business in each failure scenario. Most founders know the dependency exists. The question is whether anyone has run the scenario honestly and built a plan from the answer. That is the conversation this tool is designed to open.

Take the interrogator →