How to Charge for Maintaining an AI-Built App
AI made build cost cheap without making maintenance cheap, which breaks percentage-of-build pricing. A tier structure and a floor calculation that hold up.
How to Charge for Maintaining an AI-Built App
Charge a monthly retainer that covers a defined list, and bill everything else hourly. The mistake that eats agencies alive is quoting maintenance as a percentage of the build price, because an app built in three days with AI has a build price that bears no relationship to what it costs to keep running. The build got cheap. Maintenance did not.
Why the old percentage rule broke
The traditional number was 15 to 20 percent of build cost per year. That worked when build cost tracked complexity, because a complex app cost more to build and more to maintain. AI severed that link. You can now build in two days something that would have taken six weeks, and it has exactly the same number of dependencies to patch, integrations to watch and customers to support as the six-week version.
Twenty percent of a two-day build is a retainer that cannot cover a single serious incident. Price maintenance from the ongoing work, not from the build.
What is actually in the ongoing work
Category | Roughly how often | Who notices if you skip it |
|---|---|---|
Dependency and security updates | Monthly | Nobody, until something is exploited |
Provider and API changes | Unpredictable, several times a year | The client, immediately, when a feature stops working |
Model deprecations and behaviour shifts | A few times a year | The client, as output quality complaints |
Hosting, uptime, backups verified | Continuous, checked monthly | Everyone, at the worst moment |
Small content and copy changes | Weekly if you allow it | This is the one that silently consumes the retainer |
That last row is where retainers die. Unbounded small requests are unbounded. The retainer needs a number attached to them.
A structure that holds up
Three tiers, each defined by what is included rather than by hours, with an explicit hourly rate for anything outside:
Tier | Includes | Typical shape |
|---|---|---|
Keep it alive | Updates, monitoring, backups, uptime response. No changes. | Lowest price, highest margin, easiest to deliver |
Keep it current | The above, plus provider and model migrations, plus a capped number of small changes | Most clients belong here |
Keep it moving | The above, plus a monthly block of development time that does not roll over | Effectively a part-time retainer with a support floor |
Two rules make this work. Small changes are capped per month and stated as a count, not hours, because clients understand "four small changes" and argue about hours. And unused development time does not roll over, otherwise you are carrying a liability that surfaces all at once in month six.
Price the floor before the tiers
Work out what the cheapest tier must earn before you name any numbers. That floor is: your time for the monthly maintenance pass, plus an amortised allowance for the incidents you know will happen, plus the cost of simply being reachable. A retainer that does not clear the floor loses money on its best months and much more on its worst.
The amortised incident allowance is the part people leave out. If a serious break takes a day and happens twice a year across ten clients, that is twenty days a year you have already committed to and are not charging for.
Put the model risk in writing
Maintenance on an AI-built app carries a category of change that traditional contracts never had: the model underneath can be retired or can shift behaviour, and the client will experience that as your app breaking. Name it in the agreement, say which tier covers migration work, and say what happens if a provider forces a change on short notice. Clients are reasonable about this when told in advance and furious about it when it arrives as a surprise invoice. The related scoping trap is covered in keeping a productised service from turning into custom work.
Common mistakes
Quoting maintenance as a percentage of a build price that AI made artificially small.
Including "reasonable support" without defining reasonable, which the client will define for you.
Rolling over unused hours, turning a retainer into an accruing debt.
Charging the same for an app with three integrations and one with fifteen. Integrations, not features, drive maintenance load.
Not charging for being on call, which is a real cost even in months when nothing happens.
If you are setting the build number as well, pricing the build itself covers that side, and the two quotes should be presented together so the client sees the total cost of ownership rather than an attractive build price followed by a surprise. Broader context sits in the wider view on making money with AI, and if the app is your own product rather than a client's, pricing a SaaS for its first customers is the more relevant piece.
Frequently asked questions
What percentage of build cost should maintenance be?
None, for AI-built apps. The old 15 to 20 percent rule assumed build cost tracked complexity, and it no longer does. Price from the ongoing work instead.
Should maintenance be monthly or annual?
Monthly, billed in advance, with a notice period. Annual prepayment sounds attractive but makes it much harder to reprice when a client's app grows.
How do I handle an emergency outside the retainer?
Define an out-of-hours rate in the agreement before you ever need it. Negotiating a rate during an incident is bad for both sides.
Can I charge maintenance if the client built it themselves with AI?
Yes, and it is often priced higher, because you are inheriting code you did not write and cannot vouch for. Do a paid audit first and price the retainer after you have seen it.
How did this land?
About the author
Growth & SEO Lead
Manuele covers distribution: SEO, content strategy, and how AI-built products find their first thousand users. He tests everything he recommends.
