You can own the application without owning the model.
Software ownership is not one thing. The rights to code, data, model weights and cloud infrastructure belong to different contracts. Good engineering makes the boundaries understandable.
CEO, CIO, CPO, CFO
The argument in brief.
Buy control over what differentiates your organization and an explicit understanding of what remains external. Ownership is a boundary to negotiate and test, not a slogan.
The real autonomy test
Ask a second engineer, not involved in the build, to run the application from documentation in a clean approved environment. Can they understand where data flows, how permissions work, which APIs are licensed, how costs accrue and what to do when a deployment fails? Can they make a small change and verify it? That is a more meaningful test of operational autonomy than the presence of a GitHub repository.
Read the reasoningWhen recurring support is still rational
A company may prefer to retain the engineering firm because monitoring, upgrades and integrations require ongoing attention. That is reasonable if the support contract is transparent and the client could engage another qualified team. Optional maintenance is compatible with ownership; technical hostage-taking is not.
Read the reasoningThe reasoning behind the recommendation.
A company considers a $75,000 custom AI application. The appeal is immediate: pay for an asset instead of a recurring agency subscription. Its developers can extend the software using their preferred coding tools, and the company is not dependent on one outside team to change a form or add a feature.
That independence can be valuable. But it is easy to oversell. Owning a repository does not mean the company owns the model API, the cloud account configuration, every package in the dependency graph or the ongoing labor required to keep the product reliable.
Five layers of control
1. Business data
The company may own its source information, but contracts, permissions and third-party data rights still govern how it may be processed. The application must preserve those constraints. A data export should not be mistaken for ownership of an external database or a customer's confidential content.
2. Custom source code and intellectual property
This is what most buyers mean by custom software ownership. The agreement can assign bespoke deliverables to the client, define what happens upon payment and establish rights to repositories, build scripts, tests and documentation. Not every project uses the same contract. Pre-existing frameworks and open-source components may carry separate licenses.
3. Model services and weights
An enterprise API provides a service under terms. It does not transfer ownership of its foundation model. A licensed open-weight model offers a different form of control, but that license may restrict use, distribution or derivatives. Fine-tuning may create artifacts without conveying the rights to underlying weights. These distinctions should be documented before work begins.
4. Infrastructure
The client can control cloud accounts, secrets, deployments, network boundaries and logs without necessarily owning the physical infrastructure. Self-hosting shifts operating responsibility toward the organization; it does not make that responsibility disappear.
5. Operating knowledge
This layer is often forgotten. A repository without architecture notes, secrets inventory, environment setup, test cases, incident procedures and dependency versions can leave the company more dependent than it expected. Knowledge transfer is an engineering deliverable, not a ceremonial handover meeting.
The real autonomy test
Ask a second engineer, not involved in the build, to run the application from documentation in a clean approved environment. Can they understand where data flows, how permissions work, which APIs are licensed, how costs accrue and what to do when a deployment fails? Can they make a small change and verify it? That is a more meaningful test of operational autonomy than the presence of a GitHub repository.
When recurring support is still rational
A company may prefer to retain the engineering firm because monitoring, upgrades and integrations require ongoing attention. That is reasonable if the support contract is transparent and the client could engage another qualified team. Optional maintenance is compatible with ownership; technical hostage-taking is not.
At the other extreme, an enterprise may prefer a packaged managed service because it does not want to own operations. A technology-neutral advisor should be prepared to recommend that path.
The distinction AI coding agents do not erase
Claude, Codex and other engineering tools may help a client modify software. They don't automatically preserve architectural invariants, approve production changes, resolve licensing or accept security risk. Professional engineering still establishes what must remain true after the change.
McKinsey's 2026 survey suggests that more organizations are reconsidering software purchases because internal development has become more accessible. That is a good reason to improve handover practices, not to declare that maintenance is free. [1]
The decision rule: Buy control over what differentiates your organization and an explicit understanding of what remains external. Ownership is a boundary to negotiate and test, not a slogan.
Sources and limitations
[1] McKinsey, The state of AI in 2026, August 2026.
[2] NIST, AI RMF Generative AI Profile, July 2024: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence.
[3] Third-party license and privacy terms are vendor/product/contract specific. Legal questions require qualified counsel.
Source notes
References supplied with this manuscript. Source scope and limitations are retained; inclusion is not an endorsement of every claim.
- The state of AI in 2026 McKinsey
Verify actual wording and survey population when quoted; does not mean SaaS is obsolete.
- Generative AI Profile for AI RMF NIST
Not legal certification, nor proof of Marmation compliance. Not certification of Marmation practices