After AI Delivery: Why "Full Source Code Handover" Is the Real Ownership Test

Post-delivery dependency is designed into AI systems — and can be avoided before you sign

For Hong Kong companies working with independent AI engineers, the biggest hidden concern is not price and it is not technology — it is post-delivery dependency.

"What if he stops responding later?" "Who fixes it when it breaks?" "Does he want me on a monthly retainer forever?"

These questions are rarely asked directly at the pricing stage, but they are the real reason many companies ultimately don't start. This article explains what a professional delivery model should look like, and what to verify before you sign.

How Dependency Gets Designed Into AI Systems

Many AI solution business models in the market are deliberately built on dependency.

The most common form: the system runs on the vendor's own servers, uses the vendor's API keys, connects to the vendor's database. On the surface you "own" this system; in reality what you own is a login account. The vendor disappears, the system disappears immediately.

The second form: the deliverable is an undocumented black box. The code may genuinely have been handed over, but with no deployment instructions, no architecture documentation, no configuration guide. In theory you own the source code; in practice, without the original engineer, nobody can operate it.

Both forms create the same outcome: you think you bought a system; you actually bought a permanent relationship — and the other party controls the pricing.

True Ownership Has Four Verifiable Standards

First: The system runs on your infrastructure. Your cloud account, your API keys, your database. The engineer has no access after delivery. This should be stated explicitly in the contract.

Second: Complete source code delivery, including buildability. Not just a collection of code files — a complete package that a competent engineer can independently deploy, modify, and maintain.

Third: Documentation is a deliverable, not an add-on service. Deployment steps, architecture overview, configuration options, common issue handling. Documentation quality directly determines your future freedom.

Fourth: The handover period has a clearly defined scope. A professional contract specifies the knowledge transfer scope — perhaps a few days of walkthrough, perhaps documentation-based handover. The key: it has an endpoint, it does not run indefinitely.

"So How Does the Engineer Make Long-Term Income?" — The Honest Answer Should Reassure You

A reasonable question: if the engineer delivers with no ongoing dependency, where is the long-term income?

The honest answer has two parts. First, ongoing support is charged by the hour, separately — you pay when you need it, not when you don't. This is structurally different from "fixed monthly fee or the system stops" — in the former you are a client, in the latter you are a hostage.

Second, new projects. A well-delivered system creates demand for automating the next workflow. An engineer's long-term income should come from the quality of what they deliver, not from your exit costs.

Before signing, ask directly: "If we don't work together after delivery, what limitations will we have using this system?" The answer should be "none." Any other answer deserves a follow-up.

The LLM Era Makes This Question More Important

Traditional software is static after delivery. AI systems are not — the underlying LLM model keeps upgrading, APIs change versions, cost structures shift.

This means two things. First, systems should be designed with direct API integration, avoiding unnecessary intermediate frameworks — each additional framework layer is one more thing that can break later. Second, your system should benefit from model upgrades without requiring a rebuild — with API-based architecture, model upgrades are automatic; with custom-trained models, each upgrade is a new project.

Architecture choices are not just technical decisions — they determine your future freedom.

Pre-Signing Checklist

Does the contract specify complete source code delivery, including delivery method?

Does the system run on your own cloud account and API keys?

Is documentation explicitly listed as a deliverable?

Is the handover and knowledge transfer scope defined?

Is ongoing support structured as "billed on demand" rather than "mandatory monthly fee"?

When you ask "What limitations do we have after delivery if we don't work together" — is the answer "none"?

Six questions, five minutes. The vendor's responses will tell you whether their business model is built on delivery quality or on your exit costs.