TL;DR: Software keeps costing money after launch because the world under it keeps moving: operating systems, app store rules, third-party APIs, AI models, open-source dependencies and security threats all change on their own schedule. Maintenance is the work of keeping a shipped product safe, working and current, and it is separate from building new features. Budget for it before launch, decide who watches what, pick a support model that matches how critical the product is, and make sure whoever maintains it can actually be replaced. Teams that skip this do not save money. They pay later, in a rushed fix after something breaks in front of customers.
Most buyers budget carefully for the build and almost not at all for what comes after. Then, months later, a login stops working on the newest phones, a payment provider retires an API version, or a security advisory lands for a library the app depends on. None of it is anyone's fault. It is what happens to every product that stays in use.
This guide covers what actually changes under a live web or mobile product, the different kinds of maintenance work, the support models you can choose between, and the questions to settle before launch. Immersive products have their own, faster-moving version of this problem, which we cover separately in XR app maintenance.
Why finished software does not stay finished
Your code may not change at all after launch, but almost everything it depends on will. A typical product sits on top of:
- Operating systems and browsers. iOS, Android and the major browsers ship new versions every year, sometimes changing permissions, background behavior or how older APIs work.
- App store requirements. Apple and Google regularly raise the minimum SDK level, add privacy disclosure rules and change review policies. An app that falls behind can be blocked from publishing updates, which matters the day you need an urgent fix. We cover the release side in the app store release process.
- Third-party services. Payments, email, SMS, maps, analytics, login providers and CRMs all version their APIs and eventually retire old ones, usually with notice that goes to whoever owns the developer account.
- Open-source dependencies. A modern app pulls in hundreds of packages. Some get security fixes, some get abandoned, and some make breaking changes in a new major version.
- Infrastructure. Hosting platforms retire old runtime versions, certificates expire, databases need upgrades and cloud bills drift upward as usage grows.
- AI models. If your product calls a hosted model, the provider will eventually deprecate the version you tested against. A newer model is usually better on average, but it can behave differently on your specific prompts, which is why we treat model upgrades as a change that needs testing, as described in evaluating AI features.
The longer these changes are ignored, the more they stack up. One deferred upgrade is an afternoon. Three years of deferred upgrades can turn into a project, and sometimes into the reason a product needs modernizing or rebuilding.
The four kinds of maintenance work
It helps to separate maintenance into types, because they are budgeted and scheduled differently.
Corrective: fixing what breaks
Bugs that real users find, crashes that show up in monitoring, and edge cases that testing missed. Some are urgent, most are not, and the important part is having a way to tell the difference quickly.
Adaptive: keeping up with the platform
Everything in the list above: OS updates, store requirements, API retirements, model deprecations and runtime upgrades. This work is predictable in kind but not always in timing, and it is the category most often forgotten in budgets.
Preventive: reducing future cost
Dependency updates done in small steps, test coverage on the flows that matter, removing dead code, improving logging. Nobody notices this work when it is done well, which is exactly why it gets cut first and why its absence shows up as expensive surprises later.
Security: closing holes before someone uses them
Patching vulnerable dependencies, rotating keys, reviewing access, renewing certificates and responding to advisories. For anything that handles money, health information or personal data, this is not optional, and it should have a named owner.
New features are deliberately not on this list. They matter, but mixing them into a maintenance budget is how teams end up with neither: the feature work expands and the upkeep quietly stops.
What it looks like in practice
We maintain products of our own as well as client builds, so this is not theoretical for us. LectureNotes AI, Lifemaxxing AI and Fyuel are live products we build, own and run, and each has a different maintenance profile.
- Consumer AI mobile apps like LectureNotes AI and Lifemaxxing AI live on two app stores and depend on hosted AI models. The recurring work is store compliance, OS updates, model changes and keeping per-user AI costs under control as usage grows, which we discuss in controlling AI costs.
- Business software like Fyuel, an accounting platform for the fuel trade, has fewer platform surprises but a lower tolerance for errors. Ledgers and reports have to stay correct, so changes need careful regression testing and data handling, as covered in building financial software.
- SDKs and infrastructure, like the cross-platform SDKs we built for Geonode, have a different problem again: other developers' apps depend on yours, so every change has to stay compatible across platforms and versions. We go into that in cross-platform SDK development.
- Voice AI systems like the ones we build with CallGuard AI and CallSetter AI need live monitoring rather than occasional check-ins, because a broken call flow loses leads in real time. That is a support model of its own, described in AI voice agent monitoring.
The point is that "maintenance" is not one thing. The right plan depends on what the product is, who depends on it and what failure costs.
Choosing a support model
There are three common models, and each fits a different situation.
Ad hoc, paid when needed
You call the team when something breaks or needs changing and pay for the time. This works for internal tools, early prototypes or products with very few users. The risk is that nobody is watching in between, so adaptive and security work only happens after something fails, and the team you call may no longer have context or availability.
A monthly retainer
A fixed block of hours or a fixed scope each month covers monitoring, updates, small fixes and an agreed response time. This suits most live products with paying customers. A good retainer spells out what is included, what counts as new work, how quickly urgent issues get a response and what happens to unused hours. If those terms are vague, the retainer tends to drift into either unpaid feature work or paid idle time. The trade-offs mirror the ones in fixed price vs time and materials.
An in-house owner, with outside help
Once a product is central to the business, someone on your side should own it, even if a studio still does much of the work. That person tracks the roadmap, holds the accounts and decides priorities. Outside engineers can then work as an extension of the team, which is the model described in software talent augmentation.
Products often move through all three as they grow. What matters is choosing deliberately rather than discovering the default after something breaks.
How to budget for it
There is no honest universal number, and you should be wary of anyone who quotes one without knowing your product. The cost depends on how many platforms you ship on, how many third-party services you integrate, whether you use AI models, how sensitive the data is, how much traffic you have and how much preventive work was skipped earlier.
A few principles hold regardless:
- Plan it before launch, not after. Put a maintenance line in the same budget conversation as the build, alongside the estimate from MVP development cost.
- Separate upkeep from features. Give maintenance its own budget so it does not get spent on the roadmap.
- Expect it to scale with complexity, not code size. A small app with ten integrations can cost more to maintain than a larger one with two.
- Count the hosting and service bills too. Infrastructure, AI usage, monitoring tools and store fees are recurring costs that belong in the same view.
Make the maintainer replaceable
The most expensive maintenance situation is one where only one person or one vendor can touch the product. Before launch, make sure you own the code repository, the cloud and store accounts, the domains and every third-party developer account, so that deprecation notices reach you and access does not depend on goodwill. A short written runbook, a repeatable build, automated tests on critical flows and up-to-date documentation mean another team could take over if they had to. We go through this in detail in software ownership and handover.
If you are already in the opposite situation, with a product nobody has touched in a year and a team that has moved on, the first step is usually an audit rather than a fix. Our guide to rescuing a stalled software project covers how to approach that.
Questions to settle before launch
- Who receives deprecation and security notices from each platform and service we use?
- Which flows are monitored, and who gets alerted when they fail?
- How quickly do we need a response for an outage, a serious bug and a minor issue?
- Which support model fits this product today: ad hoc, retainer or in-house owner?
- What is the monthly maintenance budget, separate from new features?
- How do we test a model, OS or dependency upgrade before users see it?
- Do we own every account and credential, and could another team take over from the documentation?
The bottom line
Launch is the start of a product's life, not the end of its cost. The platforms, services and models under your software will keep changing, and a small, steady amount of maintenance is far cheaper than an emergency fix after something breaks in front of customers. Decide the plan before you ship, keep it separate from the roadmap, and make sure the product never depends on a single person to keep it running.
Launching a product and want a maintenance plan that matches it? Book a demo and we will scope it with you. See our work: LectureNotes AI, Lifemaxxing AI, Fyuel, Geonode and more.