The Marmation ReviewDecisions3 min read / Essay

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.

Written for

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.

Put it under pressure

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 reasoning
Where the recommendation changes

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.

Read the reasoning

The 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.

  1. The state of AI in 2026 McKinsey

    Verify actual wording and survey population when quoted; does not mean SaaS is obsolete.

  2. Generative AI Profile for AI RMF NIST

    Not legal certification, nor proof of Marmation compliance. Not certification of Marmation practices

Discuss the decision in front of you Return to Decisions