Contents
- Maintaining custom software is not the same as building it.
- The 10-system portfolio was not built 10 times from scratch.
- One person can maintain this -- but that does not mean one person must.
Yes. One operator maintained a portfolio of 10 production systems across 7 verticals and 2 geographies -- processing 616,543 leads and 75,125 transactions -- with external dependency dropping to approximately 7% by the end of the build period. The key is not having superhuman capacity; it is building on reusable patterns so that maintenance compounds rather than piles up.
What "maintain" actually means at this scale
Maintaining custom software is not the same as building it. Once a system is in production and stable, maintenance involves monitoring, occasional bug fixes, and adding new features as the business requires them. The build phase is the heavy lift. Maintenance is lighter by nature.
In the documented case, the operator -- Michael George Keating -- shipped PRJ-01 (a 194,954-line platform replacing six SaaS vendors) in 74 active days. By January 2026, contractor costs dropped from a peak of $9,046/month to $0/month. External dependency fell from approximately 70% of the work in October 2025 to approximately 7% by January 2026 (CS06, git-verified).
According to Robert Glass's "Facts and Fallacies of Software Engineering" (Addison-Wesley, 2002), maintenance typically consumes 60-80% of total software lifecycle cost. But that benchmark assumes a handoff model -- one team builds, a different team maintains. When the builder is the maintainer, the ramp-up cost that drives traditional maintenance expense disappears entirely.
Why compounding makes this possible
The 10-system portfolio was not built 10 times from scratch. Each system reused patterns, services, and components from the previous ones. Build times compressed from 23-43 days for early projects down to 4-9 days for later ones. Per-project external support costs fell from $7,995 to $0 by the ninth product (CS06, audited).
This same compounding applies to maintenance. A bug fixed in the shared service layer is fixed everywhere. A pattern improvement propagates across all systems using that pattern. One person maintaining 10 systems built on shared infrastructure is fundamentally different from one person maintaining 10 independent systems.
The honest constraint
One person can maintain this -- but that does not mean one person must. The codebase is built on PHP/Laravel (standard framework), version-controlled in git, and structured with documented service layers. Any competent developer can pick it up. The operator chose to work alone because the economics allowed it, not because the architecture requires it. If the business scales to the point where a second person is needed, the onboarding path is straightforward (CS06, CS10).
Related: What happens to custom software if the developer leaves? | What are the risks of building and owning your own business software?
References
- Glass, R. (2002). "Facts and Fallacies of Software Engineering." Addison-Wesley. Software maintenance cost benchmarks (60-80% of lifecycle cost).
- Keating, M.G. (2026). "Case Study: The Full Portfolio." Stealth Labz. Read case study
- Keating, M.G. (2026). "Case Study: The Platform Displacement." Stealth Labz. Read case study