Fragile
- Accounts, hosting and code are in the builder's name
- Nothing is written down; the knowledge is entirely in one head
- If they vanish, you are negotiating for access to your own operation
What happens if the person who built my software disappears?
Straight answer up front. Then the details.
The short answer
The honest answer isn’t “don’t worry, we’re not going anywhere.” Every builder — a solo developer, an agency, an in-house employee, us — can become unavailable. Illness, a career change, a business closing, a falling out. Reassurance is not a plan.
The real answer is that the system should be prepared for it before it happens. If accounts are in your name, the code is in a repository you control, backups exist, and how it works is written down rather than remembered, then a builder leaving is an inconvenience. If none of that is true, it is an emergency — no matter how much you trust the person today.
The question to actually ask
Forget worst-case drama. The practical test is one sentence: if the person who built this disappeared tomorrow, could someone else qualified get access, understand how it works, and keep it running?
That question has a factual answer, today, for any system you already run. It doesn’t depend on trust or intentions — it depends on where the accounts, the code, the backups and the knowledge live. Engineers call this the bus factor. Contractors already know it as the same problem as the one estimator who’s the only person who knows how you price things.
And this isn’t only a custom-software risk. If your operation runs on one platform, one integration nobody understands, and one person who knows the setup, you have the same exposure with a subscription attached.
Four readiness levels
A simple way to place your system honestly. This is ACS guidance from operator experience — not an industry-certified standard, and not a score anyone else grades you against.
Dependent
- You hold credentials, but nobody has ever tested using them
- Little or no documentation; deployment is undocumented tribal knowledge
- A replacement developer could get in — then spend weeks reverse-engineering
Transferable
- Accounts, repository and credentials are yours and verified working
- Documentation covers architecture, dependencies, deployment and integrations
- Handover would be a project with a defined scope, not a rescue
Resilient
- Everything above, plus tested backups and a written recovery procedure
- Monitoring alerts someone when something breaks, before customers notice
- Continuity items are reviewed on a schedule, not assumed to still be true
Most small businesses running custom software sit at Fragile or Dependent, and don’t know it until the day it matters. Transferable is a reasonable target for almost any contractor. Resilient is worth the extra effort when the system is genuinely mission-critical — when a day of downtime costs real money.
The continuity checklist
Go through this against your current system — custom or not. Every unchecked line is a specific dependency on one person continuing to be available and cooperative.
Could someone else take over tomorrow?
- Repository access — the code lives in an account your business controls
- Admin credentials — you hold a working administrator login you've actually used
- Hosting access — the hosting account is in your name and billed to you
- Domain access — the domain is registered to your business, with you on the account
- Database access or a verified export path you have personally run
- Backups — they exist, they run automatically, and a restore has been tested
- Environment configuration — settings and keys are documented, not just 'on the server'
- Dependency list — what the system is built on, and what it requires to run
- API and integration documentation — every connection, what it does, whose account it uses
- Deployment instructions — how a change actually gets from code to live, written down
- Runbooks — what to do when the common failures happen, in order
- Known issues — the honest list of what's fragile and what's a workaround
- Monitoring — something watches the system and tells a human when it breaks
- Recovery procedure — the written steps for getting back up, and who runs them
- Contact and ownership map — every account, service and who controls it, in one document
- Third-party billing — every recurring charge visible on your payment method, not theirs
- Transition rights — the agreement says what happens to access and code at the end
None of this requires you to be technical. It requires that these things exist, that they are in your name, and that somebody has confirmed they work — ideally more than once.
How to check without a developer
Four things you can verify yourself this week
- Log in as the administratorNot the builder's account — yours. If you don't have one, or you've never used it, that's the finding.
- Run the exportExport your data and open the file. If it's unreadable, or you have to ask someone to run it for you, your data portability is theoretical.
- Find the billsCheck which recurring charges for hosting and services appear on YOUR statement. Anything that doesn't is an account you may not control.
- Ask for the handover documentRequest the documentation a replacement developer would need. How quickly and completely it arrives tells you your readiness level more accurately than any promise.
What we think a builder owes you
We’d rather be judged on this than on a promise to stick around. Continuity work is unglamorous, it takes real hours, and it exists specifically to make the builder replaceable. We think that’s the point — a system designed so you could leave is a system you’ll stay with by choice.
Ask any builder, including us, to show you what a handover would look like. The answer to “what if you disappear?” should be a document, not a reassurance.
ACS guidance — written from operator experience building systems for contractors, not from vendor marketing. Last reviewed August 10, 2026.
Reviewed by Connor Adler, Adler Custom Systems
The readiness levels and continuity checklist are ACS guidance built from operator experience, not a certified industry framework or an audit standard. Specific access, transition and documentation obligations depend on your agreement with your builder.
Our approach
We design systems around your business.
Built from inside the operation—not from the sidelines. The people doing the work help shape the system.
- Listen
- Map
- Build
- Test
- Refine
Worked with Connor
He Helped Me Believe
Robert shares how working with Connor helped him believe in himself, gain clarity around his purpose and begin turning his mission into something real.
Watch Robert’s storyWhere to go from here
Review your continuity plan
Start with how your operation actually depends on people and tools today. The audit surfaces owner dependency and single points of failure — including the ones that have nothing to do with software.
Review Your Continuity Plan- About two minutes
- No sales call required