Beyond the First Build: Who Owns Your AI-Built Software?

Artificial intelligence can make software faster and less expensive to create. Lasting value depends on whether the business can understand, operate, change and maintain what has been built.

When I began programming in 1980, getting a computer to do something useful felt like the achievement. If the program ran and produced the right answer, that was success.

Experience teaches a harder lesson. The first working version is only the beginning.

The more revealing moment comes later, when a customer asks for a different approval process, a supplier changes its integration, a security issue needs fixing or another engineer has to take over.

That is the next change.

The first build shows that the software can work. The next change tests how well the business can understand, control and evolve it.

AI changes the economics of building, not the responsibilities of ownership

Artificial intelligence (AI) coding tools can generate substantial amounts of software quickly. An experienced practitioner can use them to explore designs, create repetitive components, translate between platforms, prepare documentation and accelerate testing.

Our Espresso Engage case study records the delivery of a six-repository platform in 398 engineering hours, with $2,500 in AI compute expenditure. Those figures describe one project’s delivery effort and expenditure; they do not establish a general productivity benchmark or independently demonstrate quality, security or maintainability. The project also included substantial architecture documentation, decision records and agent working instructions—context intended to help people understand and extend the system.

AI can reduce the effort required to write code. It has not removed the need for:

• clear business rules;
• sound architecture;
• security review;
• useful tests;
• operational monitoring;
• controlled deployment;
• maintainable integrations;
• human judgement;
• accountable ownership.

As code generation becomes faster, these surrounding disciplines become more important, not less. The danger is not simply that AI might produce bad code. It is that a team can now produce more code than it can understand, review, secure or support.

The 2025 DORA State of AI-assisted Software Development report reached a similar conclusion. It describes AI as an amplifier of an organisation’s existing strengths and weaknesses, with the greatest returns coming from investment in the surrounding organisational system rather than the tools alone. Its analysis associated greater AI adoption with higher software delivery throughput and product performance, but also with greater delivery instability. These associations do not establish causation or predict the outcome for an individual team.

In practical terms, AI can help a capable organisation move faster. It can also help a poorly controlled organisation create technical debt faster.

Legal ownership is not the same as practical ownership

A contract may state that the customer owns the intellectual property (IP). That matters, but the wording needs to cover the actual deliverables and rights the organisation will need.

For UK organisations, commissioning an external developer or supplier does not automatically transfer copyright to the customer. The creator or supplier is generally the first copyright owner. A transfer of copyright requires a written assignment signed by or on behalf of the copyright owner. Without clear terms, a customer may have only a limited licence to use what was commissioned. Other jurisdictions may take a different approach, so contracts should be reviewed by an appropriate legal adviser. (GOV.UK)

AI-assisted development adds further due-diligence questions. The agreement should address source code, documentation, designs, data, generated assets and any supplier-owned components. It should also account for third-party and open-source licences, AI tool terms and any restrictions affecting the organisation’s ability to use, modify, host, transfer or appoint another provider to support the software. Understanding and recording software licence obligations is particularly important during a supplier transition. (HMRC Engineering)

But a business can own the software on paper and still be unable to operate it without the original developer.

Practical ownership has three layers:

1. Legal ownership or sufficient rights: the organisation has the rights needed to use, change, host, support, transfer and eventually decommission the relevant code, designs, data and other deliverables.
2. Technical control: the organisation can access the repositories, infrastructure, environments, accounts, data and deployment processes.
3. Operational capability: people within the organisation, or providers it can appoint, can understand, support and change the system.

If any one of those layers is missing, ownership is incomplete.

A useful test is simple:

If the original builder became unavailable tomorrow, could another competent team safely run the system and make the next important change?

Five questions help answer that.

1. Can someone else understand it?

Software does not become maintainable merely because source code exists.

A new engineer needs to understand what the system is for, how its parts fit together and why important decisions were made. Without that context, even tidy code can become difficult to change.

A maintainable system should include:

• a concise architecture overview;
• a map of components, data flows and integrations;
• the location of important business rules;
• an explanation of security and access boundaries;
• records of significant architectural decisions;
• known constraints and trade-offs;
• a glossary of business and technical terms;
• setup instructions for a new developer;
• a record of known risks and technical debt.

The objective is not to create hundreds of pages that immediately become obsolete. It is to record the information that cannot be reliably inferred from the code.

This is particularly important with AI-generated software. A coding agent can produce a plausible implementation without preserving the reasoning behind it. If that reasoning remains only in a conversation history, personal notebook or the original developer’s memory, the business does not fully own the design.

The practical test

Ask an engineer who did not build the system to:

1. set it up in a controlled environment;
2. explain its main components and dependencies;
3. locate one important business rule;
4. describe how a customer request moves through the system; and
5. identify where a proposed change should be made.

The time and assistance required will reveal more than a claim that the system is “well documented”.

2. Can it be changed confidently?

The next change need not be large to expose weaknesses in the design.

It might involve:

• adding another approval stage;
• changing a pricing rule;
• supporting a new reporting provider;
• updating an application programming interface (API);
• adding a customer field;
• replacing an identity service;
• changing how an exception is handled.

These requests expose the structure beneath the first version.

A system is easier to change when it has clear boundaries. Business rules should not be scattered through screens, database queries and integration code. Provider-specific behaviour should not be embedded throughout the core workflow. External services should be accessed through defined interfaces rather than appearing everywhere in the application.

For example, if provider-specific differences are isolated in mappings or adapters, supporting another provider may require a new mapping rather than a rebuild of the reporting process. That is a small architectural choice with significant commercial consequences: future changes become more contained, reviewable and predictable. (Deterministic Reporting Workflow)

Useful automated tests provide the other half of the answer. They should confirm business behaviour, not simply increase a coverage percentage.

A good test suite helps a team answer:

• Did the existing approval paths continue to work?
• Are calculations still correct at boundary values?
• What happens when an external provider is unavailable?
• Are unauthorised users prevented from taking an action?
• Can a failed process be retried safely?
• Has the change affected another customer, region or product?

Tests do not eliminate judgement. They create fast feedback so engineers can make changes with evidence rather than hope.

The practical test

Choose a realistic, contained change and ask a different engineer to implement it.

Measure:

• time taken to understand the affected area;
• number of components that had to change;
• ability to test the change locally;
• size and clarity of the resulting review;
• defects found during review and release;
• confidence in rolling the change back.

The result is a more useful maintainability assessment than asking whether the software follows a fashionable framework.

3. Can it be operated reliably?

A working demonstration is not an operating model.

Once software supports customers or important internal processes, someone must be responsible for its day-to-day health. That responsibility should not become clear only after the first failure.

Operational ownership should cover:

• monitoring of availability, errors and performance;
• alerts that reach someone able to act;
• logs that support investigation without unnecessarily exposing sensitive information;
• documented incident and escalation routes;
• backup schedules and retention policies;
• tested restoration procedures;
• deployment and rollback instructions;
• dependency and security updates;
• capacity, storage and usage monitoring;
• third-party service limits and failure modes;
• a named service or support owner.

Backups deserve particular attention. A successful backup job proves that data was copied somewhere. It does not prove that the business can restore the service within an acceptable time. Restoration needs to be tested.

Ownership also needs to be divided clearly. The business owner is accountable for the outcome and priorities. The technical owner is responsible for the system’s technical health. A support provider may perform operational work, but it should not become the only party capable of understanding the service.

At virtco®, handover establishes who owns the product, benefits, support and continuous improvement after the delivery team steps away.

The practical test

Ask three questions:

1. Who receives the alert if the system fails at 08:00 on Monday?
2. What will that person do first?
3. When was the recovery process last tested?

If only the original developer can answer these questions or restore the service, the business remains dependent on that individual.

4. Can the business move it?

Portability does not mean avoiding every cloud platform, software library or specialist service. Modern software is built on dependencies.

It means those dependencies are understood and the business retains enough control to make a reasoned choice about them.

The organisation should know who controls:

• source-code repositories and their history;
• cloud subscriptions and infrastructure accounts;
• domain names and Domain Name System (DNS) records;
• application stores and signing credentials;
• databases, files and data-export processes;
• deployment pipelines;
• monitoring and analytics accounts;
• third-party service contracts;
• encryption keys and secret-management systems;
• software licences and generated assets.

Access should be held through business-controlled accounts wherever possible. A critical production environment should not depend on an individual developer’s personal email address, credit card or private repository.

The organisation also needs instructions for recreating the service. Infrastructure should be documented and, where practical, defined as version-controlled configuration. Deployment should be repeatable. Data should be exportable in a usable format. Administrative control should be transferable through a secure process, with individual access reissued and secrets rotated where appropriate. Passwords, API keys and other secrets should not be included in the handover document.

There may be good reasons to remain with the original provider. They may have valuable domain knowledge and offer an effective support service. The goal is not to force a supplier change. It is to ensure that staying is a commercial decision rather than a technical necessity.

The practical test

Run a controlled portability review:

• Can the business grant repository access without the supplier?
• Can it create a new test environment from documented instructions?
• Can it retrieve a complete, usable copy of its data?
• Are all significant third-party dependencies and licence obligations listed?
• Could another provider deploy and support the application?
• What cost, delay and risk would be involved in moving?

Some transition effort is normal. An unknown or effectively impossible transition is not.

5. Are the savings lasting?

AI-assisted development can reduce the initial effort required to build software. Where those savings are demonstrated, they represent only one part of the economic picture.

A low build price can become expensive if every subsequent change requires extensive investigation, widespread regression testing or the involvement of one irreplaceable person.

Total cost of ownership should include:

• the initial build;
• cloud, model and software usage;
• monitoring and security services;
• support and incident handling;
• dependency updates;
• testing and quality assurance;
• staff onboarding and knowledge transfer;
• enhancement work;
• data migration and retention;
• eventual replacement or decommissioning.

A serious AI business case should therefore include ongoing support, governance and change costs rather than treating the implementation price as the full investment.

Useful measure	What it reveals
Lead time for a routine change	How quickly the system can respond to business needs
Support hours per month	The ongoing human effort required to keep it working
Cost per transaction or user	Whether running costs remain proportionate as usage grows
Defects discovered after release	How well testing and review protect production
Time to restore service	Whether operational recovery works in practice
Time to onboard another engineer	How dependent the system is on undocumented knowledge
Percentage of routine changes that cannot be completed without the original builder	How dependent ongoing changes are on the original builder
Age of outstanding dependency and security updates	Whether maintenance is being performed consistently

One of the most useful measures may be time to the next change: the elapsed time between agreeing a normal business change and safely releasing it.

That measure combines comprehension, architecture, testing, deployment and operational control. It shows whether the speed gained during the first build has survived into the product’s working life.

What should be included in an AI-built software handover?

A proportionate handover pack should cover five grouped areas:

• Product and technical context: architecture, data flows, business rules, integrations, significant decisions, known risks, technical debt and future-change considerations.
• Code, quality and release: source code and version history, environment setup, infrastructure, automated tests, build procedures, deployment and rollback.
• Operations and resilience: monitoring, alerts, support runbooks, incident routes, backups, restoration procedures and maintenance responsibilities.
• Control, compliance and portability: account ownership, access arrangements, data export and retention, third-party dependencies, the software bill of materials and licence obligations.
• Accountable ownership: named business, technical and support owners, together with the agreed process for knowledge transfer and continuous improvement.

Where AI tools materially contributed to the build, the handover should also record the tools and models used, any relevant account or data-handling arrangements, and any terms or provenance issues that could affect future use. The objective is not to preserve every disposable prompt. It is to retain the information needed to understand how important assets were produced and under what conditions they can be used.

The exact documentation should match the system’s scale and risk. A small internal workflow does not require the same control environment as a customer-facing financial platform.

The principle is the same in both cases: the organisation should receive enough knowledge, access and operational capability to continue without relying on memory or goodwill.

Commission for the product’s life, not just its launch

When evaluating an AI-enabled software proposal, buyers naturally ask about features, timescales and build cost.

They should also ask for evidence of ownership: a proposed handover pack, a takeover exercise, a sample change, a tested recovery process, a schedule of controlled assets and measures for lifetime cost and performance.

These expectations should be agreed before development begins. Maintainability cannot be added efficiently during a rushed handover, and operational ownership cannot be created by transferring a folder of source code on the final day.

AI makes it possible to build more software, more quickly and with smaller teams. That is a valuable change in delivery economics.

But software creates lasting value only when it becomes part of the organisation’s controlled capability: understood by more than one person, adaptable to the next requirement, recoverable when something fails and measurable throughout its life.

The first build shows that the idea can work. The next change reveals how well the business can understand, control and evolve it.

If you are considering an AI-enabled product or workflow, talk to virtco® about building a capability your business can genuinely own.