What it costs to own custom enterprise AI.

A company has grown frustrated with a collection of SaaS subscriptions. An executive asks whether the engineering team can build the features internally with coding agents and avoid the ongoing bill. In one sense, the executive is right: tools have lowered the cost of writing application code. But the license is only one part of what the software vendor was providing. The rest of the bill is harder to see until the company becomes the operator.

There is a good argument for owning technology that differentiates the business. There is a weaker argument for rebuilding commodity features purely because custom code has become easier to generate.

Five costs hide behind a custom application

Building the first version. Product discovery, workflow mapping, interaction design, architecture, engineering, testing, deployment and acceptance remain necessary. AI can accelerate parts of development while increasing the need to review generated behavior and technical consistency. The initial price is a capitalized or project investment, depending on accounting treatment, not proof of lower total cost.

Running the system. Compute, model inference, data storage, document indexing, identity integration, backups, monitoring and network usage vary with scale. A self-hosted model also requires inference hardware, capacity planning, upgrades and potentially specialized operations support. Buying a model API does not transfer responsibility for the application around it.

Maintaining the system. Dependencies change, source-system APIs are updated, vulnerabilities emerge, data contracts drift and users request improvements. The owner needs a path for testing and deploying changes, including when those changes are made by an AI coding agent.

Managing operational risk. Incident response, failed transactions, data access, permission revocation, audit history and model evaluation impose work. The cost is especially high when a wrong action is more consequential than a delayed answer.

Maintaining internal capability. Somebody must understand why the architecture was chosen. If an external firm hands over a repository without runbooks and acceptance tests, the company may nominally own the code but still depend on the original supplier to change it safely.

A simple comparison model

Do not compare a vendor's $80,000 annual license with a proposed $80,000 custom build and declare breakeven in year one. Instead evaluate the expected life of the capability.

For a buy option, include license tiers, user growth, integrations, implementation, security review, support and expected switching cost. For a build option, include original project scope, external fees, cloud/model usage, engineering and operations capacity, testing, future enhancements and exit cost. For an extend option, include add-ons and custom business logic while retaining a system of record. For integrate, include the reliability of connectors and the team required to maintain them.

Then ask what each option actually buys. A bought platform may be adequate for generic knowledge questions. A custom review interface tightly integrated into a proprietary product may create real differentiation that cannot be priced as a commodity subscription replacement.

The ownership contract has to be concrete

A promise that 'you own everything' is rarely precise. The customer may own custom source code and documentation while still licensing cloud services, libraries, commercial connectors, proprietary models and a third-party database. Provider model weights are usually not transferred when inference is consumed through an API.

A useful handover spells out code and IP assignment, repository access, dependency licenses, deployment environments, credentials, architecture decisions, evaluation datasets where transferable, tests, runbooks, source-data rights and the post-launch warranty. Clients should have the practical option to retain another engineer, with suitable security controls, without reverse-engineering an undocumented system.

When owning the software is worth it

Ownership is attractive when the software embodies company-specific behavior, is central to future products, requires unusual control, contains proprietary workflow logic or cannot be served economically by a packaged product. It is less attractive when the requested capability is widely available, undergoes constant vendor-driven change, and offers little differentiation.

Marmation's commercial model should respect both conclusions. The decision sprint is meant to make the economics visible, not manufacture a reason to commission a build.

The decision: Own what differentiates the business. Keep the operational responsibilities visible. Buy and integrate commodity capability where it fits.

Sources and limitations

Menlo Ventures 2026 Enterprise AI; McKinsey 2026 State of AI; RSM 2026 Mid-Market AI Survey. Analysis is a proposed decision framework, not an audited ROI benchmark.