Who Maintains an AI-Built App After the First Delivery?

The business needs a named maintenance owner even when an agent wrote the application. That owner may be an internal developer, a supplier or a managed team. The important question is who will notice a failure, decide what to do, perform the repair and prove that users can work again.

This proposed handover framework was reviewed September 12, 2026. It helps a buyer define operational responsibilities; it does not set legal obligations, quote a maintenance price or claim that a recovery exercise has been performed.

A delivered repository answers where the source lives. A maintenance agreement needs to answer what happens after the first failed login, expired credential or broken dependency update. The person paying for the app should be able to find the responsible owner without reconstructing the original build conversation.

The runtime-dependency reference identifies the systems an app relies on. Use that inventory as an input here. For every important dependency, add who receives alerts, who can change it, who approves recurring spend and who is available if the primary maintainer leaves.

Keep accountability and execution distinct. A business owner may approve priorities and expenditure while a technical maintainer performs the work. An agent can assist the maintainer, but assigning a task to a model does not create continuing responsibility for an unattended service.

The proposed matrix below describes responsibilities to assign. Put actual names or contracted teams into the working version, along with a backup and the relevant access route. A label such as development team is insufficient if nobody has accepted that role.

Also state what is excluded. A fix that restores agreed behavior is different from adding a new workflow. An upstream service failure differs from an application defect, but somebody must still investigate and communicate its effect. Exclusions should route the issue to an owner, not make the problem disappear.

NIST’s SSDF version 1.1, published in February 2022, treats secure development practices as part of the software life cycle. This guide uses that named framework as background; the matrix is our proposed operational aid, not an SSDF compliance assessment.

A support response can mean that someone has acknowledged the issue. Recovery means that the relevant user journey works again, or an agreed fallback is available. A buyer should not mistake a fast acknowledgment promise for a fast repair promise.

Google’s SRE guidance on service objectives distinguishes measurements, targets and agreements. Apply the measurement discipline to the app’s actual purpose: can users submit the form, retrieve the document or complete the transaction? A running server alone may not answer that question.

Choose support hours, escalation paths and severity definitions that match the business. Record who declares an incident, who communicates with users and what evidence closes it. Do not copy a fashionable availability target without understanding what is measured and what the team can operate.

GitHub’s Dependabot documentation describes automated pull requests for dependency security updates, subject to available fixes and ecosystem behavior. A proposed update is useful input. It is not evidence that the application has been repaired, tested or released.

Assign an owner for reviewing update risk, running relevant checks and choosing a deployment window. Record how urgent security fixes differ from routine version changes. If a dependency has no available fix, the maintainer still needs to assess exposure and decide whether a workaround, replacement or restriction is appropriate.

For apps using model APIs, maintenance also includes changes in model availability, output behavior and tool contracts. Preserve representative acceptance cases so a replacement can be assessed against the work the app must perform. The combined-changes guide helps prevent individually acceptable edits from becoming a broken release.

Ask the proposed maintainer to start from the handover package, make a small agreed change and show the relevant test result. Use a non-production environment or another bounded setup. The point is to reveal missing access, undocumented steps and assumptions before an incident makes them urgent.

Then ask for a recovery demonstration appropriate to the app: restore test data from a backup, return to a known release or use the documented fallback. Record what was actually restored and which checks proved it. A backup file existing somewhere is weaker evidence than a demonstrated usable restore.

Keep this an explicitly proposed drill unless it has been carried out. If a dependency cannot be exercised safely, record that limitation and the evidence still needed. The delivery-states reference explains why saved, deployed and accepted should remain separate labels.

List the accounts that must remain funded: hosting, databases, email delivery, model access, storage and any required licenses. Give each a billing owner and renewal route. Avoid presenting the initial generation cost as the cost of operating the app; ongoing work depends on its usage, dependencies and service expectations.

The exit plan should identify where source, configuration documentation, data exports, incident history and recovery instructions live. Verify that another authorized maintainer can obtain appropriate access without using the original builder’s personal credentials. Preserve continuity while removing access that is no longer needed.

For an AI transformation project, acceptance should include both the functioning app and its maintenance arrangement. Choose internal ownership, supplier maintenance or another workable model based on the responsibility it actually covers. A low initial price is not a complete answer to who owns tomorrow’s failure.