How to Quote a Rescue Job for an AI Built App

How to quote a rescue job for an AI built app comes down to one sequencing rule: never quote from a demo and a conversation. Quote the audit, deliver the audit, then quote the work. A fixed-fee audit priced at roughly a day and a half of your rate is the only responsible way to name a number for a codebase you have not read, and clients accept it far more readily than people expect, because they already suspect the thing is worse than it looks.

The failure mode this avoids is specific and common. A founder shows you an app that mostly works, asks what it would cost to finish, and you quote against the demo. Then you open the repository and discover there are no tests, the database has no constraints, and every API key is in the client bundle. You are now three weeks into a two-week quote and the relationship is already adversarial.

Why an AI built app needs a different audit

Inherited codebases have always been risky. The distribution of problems in an AI built one is different from a human-written one, and knowing where to look saves most of the time.

• The code usually runs. Generated code rarely fails obviously, which removes the earliest and cheapest warning sign you would normally get.

• The quality is uneven rather than uniformly poor. One module is genuinely fine, the next is a reimplementation of the first with different naming.

• Problems cluster in what was never specified: permissions, concurrency, error handling, and anything happening on a schedule.

• The person handing it to you often cannot tell you how it works, which is different from a developer handover and changes what you can ask.

The four checks that decide your number

Do these in order. Each one is quick, and the first that comes back badly changes the shape of the quote rather than just the size of it.

1. Data model and constraints

Open the schema before anything else. Look for foreign keys, unique constraints, not-null on the columns that matter, and whether money is stored as an integer or a float. A schema with no constraints means the data is already wrong, and cleaning production data is the single most reliably underestimated task in any rescue job.

This check alone is worth the audit fee. Broken code is cheap to replace. Broken data that has been accumulating for eight months is not.

2. Secrets and access

Grep the client bundle for keys. Check whether the database is reachable from the internet, whether row-level security is on if the platform offers it, and whether any admin route is protected by nothing but an unguessable URL. The OWASP Top Ten is a reasonable checklist to run against, and broken access control sits at the top of it for good reason: it is the most common serious finding in generated applications, because authorisation is rarely specified in the prompt that produced the feature.

3. What happens on failure

Find one external call, a payment, an email, a third-party API, and trace what happens when it fails. In a lot of generated code, the answer is nothing: the error is swallowed, the user sees success, and the record is never written. This is invisible in testing and expensive in production, and it tells you how much of the app you will need to rewrite rather than extend.

4. Change risk

Make one trivial change, something cosmetic, and see what it costs. Can you run the app locally? Is there a build step that works? Does anything tell you whether you broke something? If a one-line change takes you two hours because there is no working local environment, multiply everything in your estimate accordingly, because that tax applies to every task you will ever do on this codebase.

Your estimate is not a function of how much work there is. It is a function of how much each unit of work costs in this particular codebase.

How to quote a rescue job for an AI built app in three stages

Splitting stabilisation from new work is what keeps a rescue job from becoming open-ended. The client wants feature five. You want them to understand that features one through four are standing on something that needs fixing first, and that the two are separately priced because they are separate decisions. Presented as one blended number, the fixing looks like padding.

Credit the audit fee against the stabilisation quote if they proceed. It removes the last objection, costs you nothing when you win the work, and pays you properly when you do not. Structure the resulting engagement the way you would any other, which is to say with real payment milestones rather than a half-now half-later split.

Three findings that should make you decline

Some rescue jobs are not worth taking at any price. These are the ones to walk away from.

1. A live data breach that the client does not want to disclose. You now have knowledge and no authority, which is the worst possible position. Decline in writing.

2. The client believes the app is 90 percent finished and the audit says 40. If you cannot move them on that number before you start, you will spend the whole engagement negotiating rather than building.

3. No access to the production environment, only to a copy. You cannot fix what you cannot see, and a client who will not grant access at the start will not grant it under pressure either.

The second one is the most common and the most tempting to talk yourself past. The audit document exists partly to make that conversation possible, because it turns your opinion into a list of findings the client can read for themselves. Delivering that verdict well is a skill of its own, and much of telling a client their project will not work as imagined applies directly.

Writing the audit up

Keep it to three pages. Findings ranked by risk, each with what it is, what it could cost, and roughly what fixing it involves. Then one page of recommendation with the stabilisation scope and its price. Resist the temptation to list everything you disliked: a forty-item document reads as complaint rather than assessment and buries the three findings that actually matter.

Write it for the client, not for a developer. The person paying built this app without knowing how to code, and "missing foreign key constraints on the orders table" means nothing to them. "Two customers can currently be assigned the same order number, and roughly 40 records already have this problem" means everything. The same translation problem shows up in handing an AI built app over to a developer, from the other direction.

Frequently asked questions

What if the client will not pay for an audit?

Then quote the work with a stated range wide enough to survive what you have not seen, and say plainly which parts of the range depend on what you find. A client who will not pay a day and a half to remove that uncertainty is telling you they intend to hold you to the bottom of the range.

How long should the audit take?

A day for a small app, two for anything with real scale. If it is taking longer, that is itself a finding: a codebase you cannot assess in two days is one you cannot estimate, and the honest answer is a phased engagement rather than a fixed quote.

Should I offer to rebuild it instead?

Sometimes rebuilding is genuinely cheaper, and with generated code it is more often true than with human-written code. Make it one option in the audit with a price, not your opening position, because a rebuild proposal delivered before you have read the code sounds like a bigger invoice rather than an assessment.

How do I price ongoing support afterwards?

Separately, and not until stabilisation is finished, because the support burden of a fixed app is completely different from that of a broken one. The economics of that arrangement are covered in what maintaining an AI built app actually involves.