How to Price Post-Launch Support for an AI-Built App

Price post-launch support for an AI-built app as its own line item, separate from the build fee, sold as a defined bucket of hours or a fixed monthly scope, because "support" without a boundary quietly turns into unpaid ongoing development the moment the client's first bug report arrives.

Why this needs its own pricing conversation

Once you ship an AI-built app, the client will keep finding things: a bug that only shows up with real data, a small feature they forgot to ask for, a request to "just tweak" something that turns into a half-day of work. None of that is covered by a one-off build fee, and none of it is really a new project either. It lives in a gap most freelancers and small agencies never explicitly price, which is exactly why it becomes free.

This is a different problem from the one covered in pricing an ai agency retainer, which structures an ongoing relationship built around continued active work, new features, new initiatives, at agency scale. Post-launch support is narrower and reactive by nature: keeping something that already shipped running, not building the next thing.

Three structures that actually hold up

**1. A monthly support retainer with a defined hour cap.** For example, $400 to $1,200 a month for 3 to 8 hours of bug fixes and minor tweaks, unused hours do not roll over, hours beyond the cap bill at your standard rate. The cap is what makes this sustainable, an uncapped "unlimited support" retainer at a flat price is a bet against your own time that you will eventually lose.

**2. A pre-purchased hour block.** The client buys 10 hours upfront at a modest discount to your hourly rate, you track time against it, and you invoice for a new block once it runs out. This suits clients with irregular support needs better than a monthly retainer, since they are not paying for a quiet month.

**3. A per-incident rate with a same-day response SLA.** Priced per fix rather than per hour, with a minimum charge (say, one hour minimum even for a five-minute fix), this suits clients who want support available but do not want a recurring monthly line item. It tends to net you more per hour than a retainer, in exchange for less predictable monthly income.

What belongs in "support," and what does not

Draw this line explicitly in the agreement, because it is the actual source of scope creep, not a lack of good faith on either side:

The phrase "just a small tweak" is where this line gets tested most often. A client asking to change a button's color is support. A client asking for the button to trigger a new workflow is a feature request, however small it looks from outside.

A rough monthly rate to anchor against

Support retainers for a small AI-built app commonly land in the $400 to $1,200 monthly range for a handful of hours, scaling with the complexity of the app and your own rate. An app with real user data, payments, or integrations justifies the higher end, since a bug there carries more downside than a bug in a simple internal tool. Quote based on what a failure actually costs the client, not just on hours, the same logic that makes pricing by outcome rather than by the hour work for the initial build.

What to put in writing before the first support ticket arrives

• The exact hour cap or scope boundary, and what happens when it is exceeded, billed overage, or a hard stop until the next period.

• Response time expectations, same-day, next-business-day, whatever you can actually sustain, stated as a real commitment, not implied.

• An explicit statement that new features are quoted separately, so the first "small ask" does not set an unspoken precedent for every ask after it.

• What happens if the client wants to pause and resume the retainer, since irregular usage is common and worth planning for rather than renegotiating every time it happens.

Frequently asked questions

Should post-launch support be included in the original build price?

Generally no, for anything beyond a short initial warranty period (2 to 4 weeks covering bugs from the build itself is reasonable to bundle). Bundling ongoing support into the build price makes your original quote look larger and less competitive, while training the client to expect indefinite free support once the warranty period's boundary gets forgotten.

What if the client refuses to pay for support and expects it for free?

Treat it as a scoping conversation, not a pricing dispute. Restate clearly what the original build fee covered (the agreed feature set, working as specified) and that ongoing support is a separate, optional service. Most clients accept this once it is stated plainly; the ones who do not are worth noticing before you take on another project with them.

How do I estimate how many support hours a client will actually need?

Look at app complexity and how much real usage it is getting. A simple internal tool with light usage might need one hour a month. A customer-facing app processing payments or handling variable input will need more, since more usage surfaces more edge cases. If you are unsure, start with a smaller retainer and revisit after the first month once you have real data.

Does post-launch support pricing change once the client wants a new feature?

Yes, and this is the moment to requote. A feature request converts the work from support into a small project, priced on its own terms (fixed price or outcome-based, per your usual approach), not absorbed into the support hour bucket even if the client frames it as "just an add-on" to what already exists.

how to turn AI consulting into recurring revenue