Bus Factor Risk in Solo-Built Software: How to Ensure Continuity

The Setup

Every PE due diligence checklist includes a version of the same question: what happens if the key person disappears? In technology operations, this is the "bus factor" — the number of people who would need to be incapacitated before a project stalls. A bus factor of one is treated as an automatic red flag.

The concern is legitimate. According to the Consortium for Information & Software Quality (CISQ), poor software quality cost US organizations an estimated $2.41 trillion in 2022, with a significant portion attributable to knowledge loss during personnel transitions. Stripe's Developer Coefficient study found that 33% of developer time is spent on "bad code" — often code written by someone who left without transferring context.

For solo-built systems, the conventional risk assessment is straightforward: single operator equals single point of failure equals unacceptable risk. But this assessment conflates the risk of losing the builder with the risk of losing the system. Those are different risks — and only one of them is actually existential.

What the Data Shows

The portfolio in question — 10 production systems, 596,903 LOC, built by operator Michael George Keating — has a bus factor of one for active development. That is an acknowledged fact, not a hidden risk. The operational question is what mitigates the continuity risk, and the data provides specific answers.

First, the technology stack is standard. PRJ-01, the flagship operations platform (194,954 LOC, 135 database tables, 20 external integrations), is built on PHP/Laravel — one of the most widely deployed web frameworks globally. According to W3Techs, PHP powers 76.3% of all websites with a known server-side language. Laravel is the most popular PHP framework by GitHub stars and community size. Any competent PHP developer can read, maintain, and extend this codebase.

Second, the codebase is version-controlled with complete git history. All 2,561 commits across 10 systems are preserved, providing a full audit trail of every change, its context, and its sequence. The 1,394 commits on PRJ-01 alone constitute a detailed record of the system's evolution from inception to production.

Third, the architecture displaced six SaaS vendor dependencies — Konnektive CRM ($583/month), TrackDesk ($499/month), and four additional platforms — into a single, unified system. Monthly vendor dependency went from $1,565/month across six external platforms to $0. The system runs on standard hosting infrastructure at approximately $825/month total operating cost.

Fourth, the 12.1% portfolio defect rate (versus 20-50% industry average) means the systems are production-grade, not prototype-grade. The scaffold-based products achieved 3.7-3.9% defect rates. These are maintainable, stable systems — not fragile code that only the original author can keep running.

How It Works

The bus factor risk is mitigated through three structural decisions, not through adding personnel.

Standard technology choices: the deliberate selection of PHP/Laravel, standard database patterns, and conventional deployment pipelines means the talent pool for maintaining these systems is enormous. A Laravel developer hired from a standard job posting can read this code on day one. There is no proprietary language, no custom framework, no esoteric architecture requiring specialized knowledge.

Documentation through code structure: the 95%+ template reuse across the portfolio means patterns are consistent. Authentication works the same way in PRJ-01 as in PRJ-09. Database schemas follow the same conventions. Admin interfaces use the same component patterns. A developer maintaining one system automatically understands the others. The foundation itself is the documentation.

Operational independence from external vendors: because PRJ-01 replaced six SaaS platforms, the system has no external dependencies that could be disrupted by a vendor's business decisions. If the operator were unavailable, the systems would continue running on their hosting infrastructure. No vendor contracts to manage, no API keys expiring on third-party platforms, no subscription renewals gating operational continuity.

The honest risk assessment: active development velocity would drop significantly without the operator. The 4.6x output multiplier and the ability to ship a new product in 4-5 days are tied to the operator's accumulated foundation knowledge. But the existing systems would continue operating, and any competent developer could maintain and extend them. The risk is to growth velocity, not to operational continuity.

What This Means for Decision-Makers

The bus factor question deserves a more nuanced answer than "one is bad." A solo-built portfolio on proprietary technology with no documentation and no version control is a genuine existential risk. A solo-built portfolio on PHP/Laravel with 2,561 git commits, 95% template reuse, standard architecture patterns, and zero vendor dependencies is a different proposition entirely.

For PE operators evaluating this model, the relevant questions are: Can a replacement developer read the code? (Yes — standard framework.) Can they find the history? (Yes — full git record.) Can they maintain the systems without the original operator? (Yes — the systems are production-grade, stable, and architecturally conventional.) Will they build as fast? (No — the compounding advantage is operator-specific.) Is that acceptable? (That depends on whether you are buying ongoing development velocity or an existing asset portfolio.)

The infrastructure replacement cost is $795K-$2.9M. The monthly operating cost is $825. The systems are running. The risk is real but bounded — and it is a fundamentally different kind of risk than the due diligence shorthand "bus factor of one" typically implies.

---

Related: [C7_S142 — The Build-vs-Buy Math] | [C7_S144 — Software Quality at Scale] | [C7_S147 — 116 Days Sustained Output]

References

1. Consortium for Information & Software Quality (2022). "Cost of Poor Software Quality Report." Analysis of software quality costs including knowledge loss during personnel transitions.
2. Stripe (2023). "Developer Coefficient Study." Research on developer time spent on inherited code and knowledge transfer gaps.
3. W3Techs (2025). "PHP Usage Statistics." Server-side programming language market share data for production websites.
4. Keating, M.G. (2026). "Case Study: The Platform Displacement." Stealth Labz. Read case study