The deal is going well. The workflow is clear, the math works, the demo landed. Then someone in the room, usually the most experienced operator at the table, leans back and asks the question everyone was thinking.
"This is a custom build. What happens if the person who built it is unavailable when we need help?"
The room goes quiet, because it is the right question. And most vendors answer it badly.
Why the fear is rational
A system no one can support is a liability, not an asset. That is true whether the system is a custom AI platform, a piece of machinery, or a spreadsheet that only one analyst understands. The moment a critical workflow depends on a single person being reachable, you have bought yourself a risk that does not show up on the invoice and does not go away.
Off the shelf software hides this risk inside a vendor's size. You assume Salesforce will be there next year. You assume the support line will answer. The assumption is usually safe because the company is large, and the cost of that safety is everything that makes off the shelf software a poor fit for your actual operation: the generic workflows, the per seat pricing, the features you will never use.
Custom software flips the trade. You get a system shaped exactly to your operation, and in return the continuity question moves from the background to the foreground. The buyer who raises it is not being difficult. They are being competent.
The fear is not really about the builder. It is about the bus factor of one. If exactly one person holds the knowledge to keep a system alive, the system has a bus factor of one. That is the actual risk, and it is solvable. The builder being a person is incidental. The knowledge living in one head is the problem.
How most vendors answer it
Badly, and in three predictable ways.
Reassurance. "Do not worry, we are not going anywhere." This is the worst answer, because it asks you to solve a structural risk with trust. Trust is not a control. A handshake does not survive a founder getting sick, a firm getting acquired, or a key engineer leaving for a competitor.
Deflection. "That almost never happens." Maybe not. But the cost when it does happen is total, and you are the one who absorbs it. Low probability multiplied by catastrophic impact is exactly the kind of risk a competent operator refuses to wave away.
Lock in. The quiet answer, the one the vendor does not say out loud, is that dependency is the business model. If you cannot leave, you cannot stop paying. A vendor whose retention strategy is your inability to exit has every incentive to keep the knowledge in one head.
None of these survive contact with a serious procurement conversation. They are reassurance where structure is required.
The structural answer
The right response to the objection is not a better speech. It is a contract. Heed does not sell single point of failure dependencies, and the way you prove that is by writing the answer into the agreement before anyone signs.
Three things have to be true at the same time.
Support is contractual. The obligation to respond is owed by a team, tooling, and documented procedures, on a severity based service level agreement. It is not contingent on any one individual being at a desk. The commitment is to your impact, not to a person's calendar.
Documentation is complete. Every build ships with architecture diagrams, operational runbooks, and decision logs, written as the system is built rather than reconstructed after. The knowledge lives in the documentation, which is what dissolves the bus factor of one. A documented system is not a one person system.
Ownership has a defined path. Source escrow releases the code and documentation to you automatically on defined triggers, and full ownership transfer is available on election. The exit exists before you need it, which is the only time an exit is worth anything.
Why answering it structurally wins the deal
Here is the part most vendors miss. The objection is not a problem to survive. It is the opening to close on.
When you answer the continuity question with a handshake, you confirm the buyer's fear. When you answer it with a contract clause, an escrow trigger, and a documentation standard, you do something a reassurance can never do: you make the risk the buyer was worried about into the thing you are most prepared to discuss. The objection that was killing the deal becomes the proof that you are the right vendor.
A vendor confident enough to hand you the keys is a vendor confident in the work. Lock in is what insecure vendors sell. Optionality is what confident ones offer.
The question to bring to every AI vendor
If you are evaluating a custom AI build, raise the objection on purpose, early, and watch what happens. Ask it plainly: what happens to the code, the documentation, and my ability to operate this system if you are unavailable. A vendor who answers with reassurance is telling you the knowledge lives in one head. A vendor who answers with structure is telling you it does not.
This is the question Heed built an entire policy around. The support model, the escrow option, and the ownership path are documented in plain language, with the sample contract clauses published so you can read them before a call. See the Support and Continuity policy for the full version, or read the next post in this series on the three engagement models that make never being stranded a structural fact rather than a promise.