Issue #7 - The Lockout
Subscriber Edition
At 6 AM on a Friday, seven websites disappeared. No warning. No error message. Just gone. By midnight, every one of them was back online, running on entirely different infrastructure, and eight new frameworks existed that didn't exist that morning.
Field Note
I woke up to a message from a colleague: "Your sites are down." Not one site. All of them. Seven websites hosted through a single GitHub organization, all serving live traffic, all generating leads and delivering content.
The GitHub organization had been suspended. No advance notice. No grace period. The suspension was immediate, and every repository inside it, including the ones powering seven production websites through GitHub Pages, went dark at the same time.
Here's what was running on that single platform:
A consulting site with active client pipelines. A content hub with sixty published articles building SEO authority. A course platform processing payments. A weekly newsletter archive. And three supporting properties that fed traffic between them.
All of it, hosted on one platform. All of it, controlled by one organization account. All of it, gone in one moment.
The first instinct was panic. Seven sites. Active traffic. Client-facing pages. Revenue-generating checkout flows. The scope of the problem felt enormous.
The second instinct was better. I had a Bluehost shared hosting account that was barely being used. SSH access. File deployment tools already configured. The sites were static HTML, not complex server applications. The constraint wasn't technical capability. The constraint was time.
So the migration started. Not next week. Not after a planning phase. That morning.
Site by site, the files moved. Domain DNS records updated. SSL certificates provisioned. .htaccess rules written for clean URLs that matched the old routing. By noon, the first three sites were live. By evening, all seven were back. By midnight, the infrastructure was more resilient than it had ever been, because it was now distributed across a platform I actually controlled.
The lockout lasted less than 18 hours. But what it produced lasted permanently.
Over the following week, I built eight frameworks about infrastructure resilience. Not theoretical. Not hypothetical. Extracted directly from the decisions made under pressure during those 18 hours.
One framework mapped single points of failure using aviation disaster analysis. Another built redundancy architecture from Airbus flight control design. A third created recovery priority matrices adapted from emergency medicine triage. The series covered incident response protocols, post-mortem investigation, platform independence strategy, and backup verification, all born from one bad Friday.
The lockout didn't just force a migration. It forced a way of thinking about dependency that I would never have developed if the platform had kept working.
Case Slice Teardown
Role: Operations lead at a 12-person digital agency
Situation: The entire agency ran on a single project management platform. Client communication, task tracking, file storage, time logging, invoicing triggers, and reporting dashboards all lived in one tool. It was efficient. Everyone loved it. Then the platform had a 4-day outage during their busiest quarter. No access to client files. No visibility into deadlines. No ability to generate invoices.
Constraint: They couldn't switch platforms mid-crisis. Clients were asking for updates. Deadlines didn't pause because the tool was down.
Intervention: During the outage, they mapped every function the platform served and identified which ones had zero alternatives. They discovered that 80% of their critical workflows depended on a single vendor's uptime. After service restored, they built a dependency audit using the 30% rule: no single platform should control more than 30% of any critical function.
Outcome: Six months later, a different platform they used had a pricing change that would have tripled their costs. Because they'd already diversified, the migration took a weekend instead of a quarter. The constraint from the first outage had pre-built the resilience for the second crisis.
What's notable here: They didn't switch platforms after the outage. They kept using the same tool. But they stopped depending on it exclusively. The framework wasn't "avoid this vendor." The framework was "never let any single vendor hold the keys to everything." The dependency audit became a quarterly practice. The 30% rule became a standing policy. The crisis produced a system that prevented future crises.
The Deep Dive
There's a concept in aviation safety called the Swiss Cheese Model. Every layer of defense has holes. Accidents happen when the holes in multiple layers line up simultaneously. A single failure rarely causes a catastrophe. It takes several defenses failing at the same time.
Most people build their systems with one layer. One hosting platform. One communication tool. One revenue channel. One backup method. When that layer fails, there's nothing behind it.
The lockout exposed a perfectly aligned stack of holes. One platform hosted all sites. One account controlled all repositories. One suspension mechanism could take everything offline. The Swiss Cheese Model would have predicted this failure mode in advance.
But here's what makes constraint-driven innovation different from ordinary problem-solving: the solution space changes.
Before the lockout, the question was: "How do we optimize our GitHub Pages workflow?" The solution space was narrow. Better deployment scripts. Faster builds. More efficient caching.
After the lockout, the question became: "How do we build infrastructure that survives the loss of any single platform?" The solution space was enormous. It included hosting architecture, DNS strategy, backup verification, incident response, and platform independence, none of which existed in the original optimization question.
This is what constraints do. They don't just force you to solve problems differently. They force you to see different problems.
Issue #2 of this newsletter explored the Constraint Advantage in theory. This issue is the proof. The lockout didn't produce eight frameworks because someone decided to write about infrastructure. It produced eight frameworks because the constraint made invisible dependencies visible.
The DC-10 Pattern: In aviation, the DC-10 aircraft had a design flaw where all three hydraulic systems ran through the same section of the tail. The engineers built triple redundancy, three independent hydraulic systems, but routed them through a single physical location. When that location was damaged, all three systems failed simultaneously. Redundancy without independence is an illusion.
Seven websites on one GitHub organization is the same pattern. Multiple sites, but one point of control. The redundancy was in the content. The dependency was in the platform.
The framework that emerged from this insight, the Single Point of Failure Audit, uses a three-dimensional risk matrix borrowed from nuclear safety engineering. It maps every critical function against probability of failure, blast radius if it fails, and recovery time. The highest-risk items aren't the ones most likely to fail. They're the ones where failure affects everything.
Platform Dependency Audit
1. List every platform that controls something you can't rebuild in 24 hours.
Not tools you use. Platforms that control access to your work. If the platform disappears tomorrow morning, what can't you recreate by tomorrow night? That list is your actual dependency map, and it's probably shorter and more terrifying than you think.
2. Apply the 30% rule.
Does any single platform control more than 30% of your critical operations? Revenue, communication, content delivery, client access, team coordination. If one vendor owns more than 30% of any critical function, you don't have a tool. You have a landlord. And landlords can change the locks.
3. Test your recovery, not your backups.
Having backups is not the same as being able to restore from them. The backup you've never tested is Schrodinger's Backup: simultaneously working and not working until you actually try to use it. Run a restoration drill. Not the backup process. The restoration process. They are not the same thing.
4. Ask the pre-mortem question.
Imagine it's six months from now and your primary platform is gone. Not degraded. Gone. What would you wish you had done today? The answers to that question are your actual priorities, not the optimization tasks on your current roadmap.
The 3-line dependency audit
Open a blank document and write three lines:
Line 1: "If [platform] disappeared tomorrow, I would lose ___."
Fill in your most-used platform. Not what you'd miss. What you'd lose. Content, access, revenue, communication channels, client history.
Line 2: "The last time I tested restoring from my backups was ___."
If the answer is "never," you now know your single highest-priority task this week.
Line 3: "The one thing I could move to a second platform today is ___."
Pick the smallest, easiest migration. Do it. Not because the crisis is coming. Because the habit of independence is more valuable than any single migration.
Three lines. Three minutes. You now have a dependency map that 90% of businesses never create until after the lockout.
What's your biggest single point of failure right now?
Reply with one platform you depend on more than you should. The most common answers get explored in future issues.
The lockout produced eight frameworks in one week. Not because the crisis was planned, but because the systematic thinking was already in place. Learn the method that turns any constraint into a repeatable system.
Explore Strategic Thinking Academyor
Start with the foundation
Minimum Viable Intelligence ($297)
Strategic Thinking Weekly - Published every week
Subscribe for full access to all issues
Unsubscribe anytime - Tampa, FL