The short version. When a custom software developer disappears, or a relationship ends badly, it should be an inconvenience, not a catastrophe. It only becomes a catastrophe when the code was never handed to you, the system runs on tools only one person understands, or nobody wrote down how any of it works. Ask about these three things before you sign, and a developer walking away stops being a business-ending event.
This is the question that keeps a lot of business owners from starting a custom software project at all, and it's a fair one. You've heard about it happening, or maybe it happened to someone you know: the developer who built the system stops answering calls, or a disagreement over scope turns into a standoff, and the business is stuck running critical operations on software nobody else can touch. The fear isn't really about the code breaking. It's about being held hostage by one person's availability.
Why this happens in the first place
It happens when three things are missing at once: you don't have the source code, the system depends on a private server or account only the developer controls, and there's no documentation explaining how it fits together. Any one of these alone is recoverable. All three together means a new developer has to reverse-engineer a black box before they can even start fixing it, which costs you time and money you didn't budget for, on top of whatever the original relationship cost.
None of this is inherent to custom software. It's inherent to a specific way of building it, one where the developer keeps control as leverage. You can ask direct questions before work starts that rule this out.
Do you actually have the code, or a promise of the code
Ownership on paper means little if the code sits only in the developer's private repository. Ask where the code lives and confirm you have direct, working access to it, not a copy that shows up if you ask nicely. A developer who resists giving you real-time access to your own repository, for any reason, is telling you something about how they plan to run the relationship.
This matters even more once the system connects to other things you rely on: your Tally records, your accounting software, your existing tools. Integration work multiplies the number of places a handover can go wrong, so the access question has to be answered for every piece, not just the main application.
Does it run on standard tools, or a private setup only they know
Ask what the software runs on: which hosting, which database, which frameworks. If the honest answer is "a server I manage for you" with no separate account in your name, you don't control your own system, regardless of what the contract says about code ownership. A competent developer working in standard, widely-used technology can be replaced by another competent developer in weeks. A system built on a private stack that only one person understands cannot, no matter how good the original code is.
This is also why the accounts matter as much as the code: domain registration, hosting, database credentials. If any of these sit in the developer's name instead of yours, you don't fully own the system yet, whatever the contract says.
Is there anything written down
Ask for documentation as a deliverable, not an afterthought. It doesn't need to be exhaustive. It needs to answer the questions a new developer would ask on day one: what does each part do, where does data come from, what happens if a particular process fails. A short document that answers those honestly is worth more than a thick one nobody will read. If a developer treats documentation as optional, that absence is itself information about how they think about your dependency on them.
This is where a system like a custom CRM or an inventory tool tends to accumulate the most undocumented logic over time, because the rules that decide who gets a follow-up call or how stock gets reconciled were built one edge case at a time. Get those decisions written down as they're made, not reconstructed later from memory.
What a fair handover actually looks like
A project set up correctly gives you three things by the time it's live: the code in a repository you control, the accounts and hosting in your name, and documentation that explains the system to someone who has never seen it. None of this is unusual to ask for. A developer who is confident in their own work has no reason to withhold any of it, because none of it stops them from getting paid or continuing the relationship if it's going well.
If a relationship does end badly, this is what determines whether you're stuck. With those three things in hand, you bring in a different developer, they read the documentation, and they start from a working system instead of a mystery. Without them, every disagreement becomes leverage, because walking away costs you more than staying, even on bad terms.
What to ask before you sign anything
Before any custom software project starts, ask for the answers to three questions in writing: where does the code live and who has access to it right now, whose name are the domain and hosting registered under, and what documentation will you receive and when. A serious developer answers all three without hesitation, because the honest answer protects both sides. If you get a vague answer, a delay, or a reason why it's complicated, treat that as the actual answer, and look elsewhere before you've paid for anything.
None of this requires a lawyer or a long negotiation. It requires asking the question early, while you still have the leverage to walk away, instead of after the system is running your operation and someone else is the only person who understands it.