{"slug": "who-maintains-an-ai-built-app-after-the-first-delivery", "title": "Who Maintains an AI-Built App After the First Delivery?", "summary": "Digital Applied published a proposed maintenance responsibility matrix on September 12, 2026, to help buyers of AI-built applications assign a named owner for post-delivery upkeep. The framework separates incident response from recovery and requires acceptance evidence such as a tested alert, a reviewed change, and a scoped recovery drill, while noting it is not a contract template or an SSDF compliance assessment. It cites NIST's SSDF version 1.1, published in February 2022, as background.", "body_md": "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.\n\nThis 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.\n\n1. 01Assign actions to people.A repository and a support inbox do not establish who will fix a problem.\n2. 02Separate response from recovery.Acknowledging an incident and restoring the user journey are different outcomes.\n3. 03Rehearse the handover.Ask the maintainer to perform a bounded change and demonstrate recovery before acceptance.\n\n## 01 — Practical decisionMove from owning files to owning the next decision\n\nA 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.\n\nThe [runtime-dependency reference](/blog/ai-built-app-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.\n\nKeep 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.\n\n## 02 — Practical decisionMake the maintenance boundary explicit\n\nThe 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.\n\nAlso 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.\n\n[NIST’s SSDF version 1.1](https://csrc.nist.gov/pubs/sp/800/218/final), 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.\n\n| Digital Applied proposed maintenance responsibility matrix, September 12, 2026. Assign real owners and evidence; this is not a completed handover or a contract template. |  |  | \n|---|---|---|\n| Responsibility | Owner must decide | Acceptance evidence | \n|---|---|---|\n| Incident response | Who receives and triages failures? | A tested alert and reachable escalation path. | \n| Application fixes | Who restores agreed behavior? | A reviewed change with relevant checks. | \n| Dependencies | Who reviews and releases updates? | An update record and deployed-version evidence. | \n| Access and secrets | Who maintains authorized access? | A usable access inventory and rotation process. | \n| Backups and recovery | Who restores data or service? | A scoped recovery drill with observed results. | \n| Recurring costs | Who approves and pays the bills? | Named account owners and renewal arrangements. | \n| User communication | Who explains incidents and changes? | Agreed channels and responsibility. | \n| Exit and handover | Who transfers continuing responsibility? | A receiving maintainer’s acceptance record. | \n\n## 03 — Practical decisionAgree what a useful response and a useful recovery mean\n\nA 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.\n\n[Google’s SRE guidance on service objectives](https://sre.google/sre-book/service-level-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.\n\nChoose 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.\n\n## 04 — Practical decisionMake dependency updates someone’s work\n\n[GitHub’s Dependabot documentation](https://docs.github.com/en/code-security/concepts/supply-chain-security/dependabot-security-updates) 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.\n\nAssign 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.\n\nFor 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](/blog/ai-coding-agent-combined-changes) helps prevent individually acceptable edits from becoming a broken release.\n\n## 05 — Practical decisionRehearse a repair and a recovery before handover\n\nAsk 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.\n\nThen 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.\n\nKeep 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](/blog/ai-agent-delivery-states-reference) explains why saved, deployed and accepted should remain separate labels.\n\n## 06 — Practical decisionPlan recurring costs and the maintainer’s exit\n\nList 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.\n\nThe 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.\n\nFor an [AI transformation project](/services/ai-transformation), 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.\n\nEvidence and scope\n\n- As-of date\n- September 12, 2026: sources retrieved and reviewed. September 12 is the editorial allocation. Verified event dates are stated separately.\n- Sources and method\n- Original responsibility matrix informed by NIST SSDF 1.1, GitHub Dependabot documentation and Google SRE service-objective guidance. Sources checked September 12, 2026.\n- Limits\n- No live handover or recovery exercise, price estimate, legal analysis or compliance claim.\n\n## 07 — Next stepAccept the maintainer as well as the application\n\n### Accept the maintainer as well as the application\n\nA useful handover names the people responsible for repairs, access, costs and recovery. Verify that the maintainer can work from the delivered package and prove a bounded result. The app is easier to operate when responsibility survives the end of the build session.", "url": "https://wpnews.pro/news/who-maintains-an-ai-built-app-after-the-first-delivery", "canonical_source": "https://www.digitalapplied.com/blog/ai-built-app-maintenance-ownership-guide", "published_at": "2026-09-12 00:00:00+00:00", "updated_at": "2026-09-12 19:24:38.823685+00:00", "lang": "en", "topics": ["ai-products", "ai-agents", "ai-policy"], "entities": ["Digital Applied", "NIST", "SSDF version 1.1"], "alternates": {"html": "https://wpnews.pro/news/who-maintains-an-ai-built-app-after-the-first-delivery", "markdown": "https://wpnews.pro/news/who-maintains-an-ai-built-app-after-the-first-delivery.md", "text": "https://wpnews.pro/news/who-maintains-an-ai-built-app-after-the-first-delivery.txt", "jsonld": "https://wpnews.pro/news/who-maintains-an-ai-built-app-after-the-first-delivery.jsonld"}}