There's a pattern I've watched play out at probably twenty businesses now, and the script never really changes. It usually starts with someone exceptional — a long-time partner, an ops manager, a contractor who's been around so long they're basically family. They're sharp, they care, and they can build. Maybe they're a developer-by-hobby. Maybe they're an Excel whiz who graduated to Airtable. Maybe they're a process-minded operator who picked up Lovable last year and ran with it. Whatever the path, they built the thing.
The thing works. Better than the thing it replaced. People stop using the old way, then forget the old way existed, and after a while the new way becomes "how we do that here." Nobody marks the moment. There's no ceremony for the transition from "internal tool" to "operationally critical system." It just happens, sometime late on a quiet Wednesday afternoon, and from then on the business runs on it.
Three years pass. Five.
Then one of these things happens. The partner takes a sabbatical. The ops manager retires. The contractor lands a bigger client and stops returning emails as quickly. The family member moves on to something else. None of these are catastrophes. They're life. The person doesn't necessarily even leave — they just become 30% as available as they were last year, in a context where the system needed them at 100% to keep running smoothly. And the business slowly realizes a thing it didn't want to realize: nobody else has any idea how that system actually works.
There's no documentation. There's no runbook. The deploy process lives in someone's notes app. The credentials are in a 1Password vault that has one named owner. The "how I'd onboard a successor" plan was always in the back of someone's mind, never written down. The structure of the data is undocumented. The integrations are duct-taped through scripts that exist in a folder on a personal laptop. The architecture is "in [name]'s head."
Notice what just happened in that paragraph: nothing in it is a software problem. It's an institutional risk problem. The system is fine. The code is fine. Everything is running. The risk is that the business has built a load-bearing column out of one human's working memory.
This shows up in due diligence brutally. When an acquirer runs financial diligence on a $25M services company, they discover, very quickly, that a meaningful chunk of how the business actually runs sits inside an internal tool authored by one person who has no successor and no documentation. The diligence finding isn't "this is bad software." It's "this is a single point of failure with a name." That hits valuation.
It shows up in operational risk in less dramatic ways too. Bug fixes take three weeks because [name] is slammed on their actual job. New hires can't be brought into the system because there's nothing to bring them into. Process changes are blocked because nobody else can change how the data is structured. The business slowly stops being able to move on its most important workflow, because the workflow is hostage to a person.
The catch — and this is the part that catches founders off guard — is that the more critical the system gets, the worse the dependence becomes. Successful internal tools accumulate edge cases, integrations, business rules. Each addition makes the institutional risk denser. The thing that was once "Marc's neat little tracker" is now the system that ten people use every day to do the work the business gets paid for, and it still has Marc as its only brain.
The fix isn't to fire Marc. Marc is your best person. The fix is to turn the institutional risk into an institutional asset.
That means writing down what the system does, with the discipline of an actual handoff document. Putting source control around it. Separating the testing environment from production. Getting credentials out of code and into a vault. Getting changes behind a review and rollback process. Getting monitoring on it. Getting backups that have actually been restored from. It means making the system framework-compatible — meaning a competent operator who has never seen it before could walk up to it and run it correctly within a day, because every system they operate looks the same way at the seams.
Once that's done, Marc is no longer the load-bearing column. Marc is now an upgrade — a person whose deep context makes a well-operated system run even better. That's where you want a Marc. Not as the only thing keeping the system alive. The shift from institutional risk to institutional asset is what ops discipline actually buys you in this category. The system was already valuable. Now you can keep it.