In the first post in this series we named the objection that stalls most custom AI deals: what happens when the builder is gone. The honest answer is not a speech. It is a structure. Here is the structure, in plain terms.
There are three engagement models. Each one removes the dependency concern in a different way, and each one trades control against convenience at a different ratio. You do not have to choose perfectly on day one, because the models connect. But it helps to understand all three before you pick where to start.
Door one: Managed SaaS
We host it, monitor it, patch it, and keep the models current. Your team accesses your data and your outputs through a secure interface. You do not touch infrastructure or code, and the point is that you do not need to.
This is the model most clients should choose, and not as a fallback. Managed SaaS is the right default because it puts the operating burden where the expertise is. Hosting, monitoring, patching, model maintenance, security, and uptime are our problem, handled end to end. You get a predictable monthly cost with no surprise infrastructure bills, and support that runs on a severity based service level agreement rather than on whether one person happens to be reachable.
The continuity concern does not disappear under managed SaaS. It is answered two ways. First, the support obligation is owed by a team and documented procedures, so day to day operation never rests on one individual. Second, you can attach source escrow as an add on, which closes the worst case scenario without changing how the system runs day to day.
Convenience is not the same as dependency. The reason managed SaaS feels risky to some buyers is that it sounds like handing over the keys. It is the opposite. You hold the keys, in escrow, while we carry the operating weight. You get the convenience of not running infrastructure and the security of a defined exit at the same time.
Door two: Source Escrow and Continuity
For organizations that need certainty in writing, your source code and full documentation are held under a continuity arrangement, in escrow with a third party agent or in a release triggered repository. The deposit is updated on a regular interval so it never goes stale.
If defined trigger conditions are met, the materials release to you automatically, along with a license to operate and maintain the system for your business. The triggers are written into the contract. Typical ones are the firm ceasing operations or being dissolved, or a failure to meet critical severity support obligations for a continuous period after written notice.
This is the model for the risk sensitive buyer, the regulated industry, and the board that needs the continuity question answered before it will approve the spend. It is an add on to any managed SaaS engagement and it costs little to offer, because the documentation that makes it meaningful is already produced as part of every build. The single point of failure risk is closed before the contract is signed, which is the only time closing it is worth anything.
Door three: Full Ownership Transfer
Want to own the system outright? A separate license and transfer fee delivers the source code, complete documentation, and a structured knowledge transfer window so your team can run it independently. After transfer, hosting and maintenance become yours, and any ongoing support is optional and handled by retainer.
Ownership comes two ways, and the difference is about reuse, not quality.
Non exclusive purchase. You own a full copy of the code and may operate and modify it freely. Heed continues to reuse the generalized solution in other engagements. This is the cheaper option and the right default for most buyers who want ownership, because you are paying for a copy, not for exclusivity.
Exclusive purchase. You own the solution and Heed stops reusing that specific build. It is priced higher because it removes the work from our reusable library. Generally applicable methods, know how, and pre existing IP that is not unique to your system are carved out of the exclusivity, which protects the foundations every project is built on.
Which one is right for you
Start with managed SaaS unless you have a specific reason not to. It is the lowest operating burden, the fastest to stand up, and the model where the expertise carrying your system matches the people who built it. Most organizations never need more than managed SaaS plus the option of escrow.
Add escrow when the continuity question has to be answered in writing for a board, an auditor, or a regulated workflow. It is inexpensive, it does not change daily operation, and it converts a worry into a clause.
Choose full ownership when you have the internal engineering capacity to run the system yourself and a strategic reason to bring it fully in house. Pick non exclusive unless exclusivity is genuinely worth the premium to your business.
The three models are the written form of one promise: you are never locked in, and you are never stranded. The Support and Continuity policy lays out all three with the sample contract clauses, and the next post explains why the documentation underneath all three is the part that actually makes them work.