AI App Maintenance: Who Looks After It?

· By Peter Lowe

Category: Operations

Illustrated colleagues planning maintenance and support for their app
**Part 3 of 3 · The business responsibility behind AI-built apps** AI app maintenance starts with a simple question: who gets the call when your app stops working on a busy Monday morning? If the answer is the person who built it in their spare time, your business needs a more dependable support plan. This article was inspired by the discussion in Ctrl Alt Dev Episode 38, hosted by [Sean Sale](https://www.linkedin.com/in/seansale/) and [Paul Rhodes](https://www.linkedin.com/in/ukwebdevelopment/). Credit to both hosts for exploring the responsibilities behind AI-built software. The business recommendations here are Smart AI Studio’s perspective. [Listen to Episode 38 — AI Wrote the App: Now Who’s Responsible For It?](https://directory.libsyn.com/episode/index/show/8e658e4a-8560-4204-9ebd-6f1db1b6ade2/id/43072413) ## Success creates a maintenance commitment The previous articles covered [choosing the right problem](/insights/ai-app-business-decision/) and [preparing an app for production](/insights/ai-app-mvp-to-production/). Once people use it regularly, the business takes on a continuing commitment to keep it useful and dependable. Imagine an enquiry tracker that removes hours of manual administration. It works well enough that staff stop updating the old spreadsheet. Then its connection to the email system fails. New enquiries no longer appear, and nobody knows whether the app is broken or business has simply gone quiet. This is an illustrative example, but it exposes a practical question: how will you notice a failure before it affects customers? Support needs to cover detection as well as repair. ## Give AI app maintenance an owner and a support route A named business owner should be responsible for whether the app still serves its purpose. That person needs to understand its importance, approve priorities and ensure support is available. They do not have to carry out technical maintenance themselves. Agree who handles technical issues and what users should do when something goes wrong. Distinguish a minor inconvenience from a failure that stops essential work. The support arrangement should explain expected response times and how urgent problems are escalated. If an agency is providing support, ask what the service includes. Fixing faults, updating software, investigating security concerns and adding new features are different activities. Understanding the coverage helps avoid surprises when the business needs help. Make sure essential accounts and documentation are available to authorised people. A business should not discover during an outage that its only access to the platform belongs to someone who has left. ## Budget for the life of the app The initial build is only one part of the cost of AI app maintenance. Hosting and platform subscriptions may continue every month. Usage charges can rise as adoption grows. Changes to connected services may require adjustments even when you have requested no new features. Staff time counts too. Someone will answer questions, check that information is accurate and decide which changes are worth making. An app that saves time in one department may create additional work elsewhere. Review the economics regularly. Compare the continuing benefit with subscriptions, support costs and internal effort. You might track time saved, enquiries handled without chasing, or reductions in rework. Choose measures that match the original problem. If the value falls, investigate why. The answer may be a modest improvement, better training or a decision to retire the app. Continuing to pay because the build felt impressive is not a business case. ## Protect the app from uncontrolled change AI can make adding a feature feel almost effortless. Each addition still needs to fit the existing workflow and be checked for unintended effects. A change to an approval screen, for example, might alter who can authorise a transaction. Agree how changes are requested, reviewed and released. Keep a record of what changed and why. Make sure there is a way to recover if an update causes problems. Ask your technical support provider what checks are appropriate before wider use. The same discipline applies when switching AI models or platform providers. Assess the impact on the actual service you deliver. An app with an AI component may need its outputs reassessed after a change; an app built using AI does not necessarily use AI when it runs. ## Plan for absence and eventual replacement Ask whether another competent person could understand and support the app from the information available. Record its purpose, key dependencies and the arrangements for access, support and recovery. Also ask how you would leave. Can you export the information in a usable form? What would migration involve? Which parts depend on one platform? Understand these questions before urgent circumstances force a decision. For a small business, proportionate planning can be straightforward. You need enough information and agreed support to avoid relying entirely on one person’s memory. The effort should reflect how much the business depends on the app. ## A practical next step for business owners List the custom apps and automations your business already uses. For each one, record its owner, support contact, running cost and consequence of failure. Where an answer is missing, agree who will fill the gap. That review may reveal a useful experiment ready for further investment, or a tool that has quietly become essential without suitable support. Either finding gives you a concrete next action. AI can help business owners create useful software more quickly. Keeping it useful requires continuing decisions about ownership, investment and the work it supports. None of this should put you off building an app or tool with AI. It can meet a genuine business need and deliver lasting value. But the build is only the start: be realistic about the time, cost and people needed to support it, maintain it and adapt it as your business changes. That preparation protects the benefit you set out to create. If the person who built your app were unavailable for a month, could your business keep using it with confidence? ## The business responsibility behind AI-built apps 1. [Before You Build an AI App, Define the Business Problem](/insights/ai-app-business-decision/) 2. [AI App Production Readiness: From MVP to Launch](/insights/ai-app-mvp-to-production/) 3. [AI App Maintenance: Who Looks After It?](/insights/ai-app-ownership-maintenance/) If you are weighing up a custom app, [talk to us about the business problem](/contact/) before committing to the build. ## FAQs ### Who should own a custom app after launch? Name a business owner to decide priorities and keep track of value, and agree who provides technical support. They need not be the same person. ### What should an AI app maintenance budget include? Allow for hosting, platform and usage charges, support, updates, security review and staff time. Compare these costs with the original business benefit regularly. ### What happens if the person who built our app leaves? Authorised colleagues should have access to essential accounts and enough documentation for another competent person to support, recover or replace the app. ### When should a business retire an app? If its value no longer justifies its costs or risks, consider improving it, moving the work to another system or retiring it. Plan how to export useful data first.

This article was written by Peter Lowe. The ideas and opinions are his own; AI was used to assist with drafting and editing.

More from Insights

All insights · Case studies

Browse the site