Fixing Someone Else's AI-Built App: Take It or Not

Take the job only if you can answer one question before you quote: what does working software look like here, and who decides? On an app someone else built with AI, that question is usually unanswerable on day one, because the thing that normally answers it, a test suite, does not exist. Fixing someone else's AI-built app is a different engagement from maintaining your own, and pricing it like maintenance is how people lose a quarter.

This is a go or no-go framework, run before you put a number on anything.

Why inherited AI-built code is its own category

Legacy code written by a person carries intent. It is often bad intent, badly expressed, but there is a mind behind the structure, and you can reconstruct it from naming, from comments, from the shape of the commits.

An app assembled over a weekend of prompting carries something else: lots of locally plausible code with no consistent global decision. Three different patterns for the same problem, because three different sessions solved it three different ways. Dependencies added to fix one error and never removed. Auth logic in two places that disagree.

The specific thing that makes it expensive is not ugliness. It is that there is usually no test suite, so you cannot tell what is broken from what is merely strange, and you cannot tell whether your fix broke something else. You are being asked to price a repair on a machine with no instruments.

The five questions, before you quote

1. Can you run it?

Not "can you read it". Can you get it running locally, with its database, against its third-party services, from a clean checkout.

If the answer is no, and nobody can tell you how, that is not a detail to sort out after signing. The time to a running local environment is the single best predictor of how the rest will go. Give yourself a timebox, two hours is fair, and treat failure as a finding.

2. Is there any test, anywhere?

One integration test that exercises the main flow changes the engagement completely. It gives you a definition of working you can point at.

If there is nothing, your first deliverable is not a fix. It is a characterisation test that captures what the app currently does, including the wrong parts, so that you have a baseline. Price that as work, because it is work.

3. What is the actual complaint?

"It is broken" is not a scope. Push until you have a reproducible sequence: this user, this action, this wrong result. Clients who cannot produce one are usually describing a performance or trust problem rather than a defect, and that is a different job.

Watch for the complaint that is really a feature request. A surprising share of rescue briefs are "it does not do the thing we never asked it to do", and if you price that as a repair you will eat the difference. The same dynamic appears in handling scope creep on an AI project.

4. Who owns the accounts?

The database, the hosting, the domain, the API keys, the app store listing. On apps built by a non-technical founder with AI, these are frequently spread across personal accounts, a departed contractor, and one service nobody can log into.

You cannot fix what you cannot deploy. Get a written list of what exists and who holds it before you quote, because account recovery can take longer than the engineering. We cover the clean version of this exchange in handing over an AI-built app to a client, which is the document you wish the last builder had written.

5. Is there anything you would refuse to ship?

Look for the three that end engagements: credentials committed to the repository, a database reachable from the open internet, and an auth check performed only in the browser. All three sit squarely in the OWASP Top 10, which is a useful shared reference when you have to explain to a non-technical owner why this is not a style objection. AI-assembled apps produce all three at a steady rate.

If you find one, you are no longer quoting a fix. You are quoting a remediation, and you should say so in writing before you touch anything, because once you have seen it, shipping around it is your problem too.

How to structure the engagement

Do not quote a fix. Quote the audit, then quote the fix.

A paid audit, fixed fee, two to five days depending on size, delivering a written findings document, a running local environment, and a scoped proposal for the repair. It solves the real problem, which is that nobody, including the client, knows what is wrong yet.

It also protects both sides. The client pays a known amount to find out where they stand, and can take that document elsewhere. You get paid to acquire the information you needed to price accurately, instead of guessing and absorbing the variance.

If the client refuses to pay for an audit, that is useful information about how the rest of the engagement will go.

Keep the stages contractually separate. The most common failure is folding stabilise and improve into one number before anyone knows the size of either. For the ongoing phase, structuring a retainer for AI app maintenance covers how to price the recurring half.

When to say no

Say no when the client wants a fixed price for "make it work" and will not pay for an audit. Say no when nobody can produce a reproducible failure and nobody will sit with you while you look for one. Say no when the owner describes the previous builder as the entire problem, with no account of what they themselves asked for, because you are next in that story.

And say no when the honest answer is a rewrite but the client is buying a repair. Telling them that early is better for everyone, and how to tell a client their AI project idea will not work covers the conversation.

FAQ

Should I charge more to work on someone else's AI-built app?

Usually yes, but the mechanism matters. Rather than adding a risk premium to a guessed number, sell a paid audit first and price the repair from findings. A premium hides uncertainty. An audit removes it.

How long should a rescue audit take?

Two to five days for most small business apps. Enough to get it running, write a characterisation test for the main flow, reproduce the reported defects, and check for the serious security failures. Longer than a week usually means the real answer is a rewrite.

What if the client will not pay for an audit?

Offer a shorter free conversation where you ask the five questions above, then decline the fixed-price repair. A client unwilling to fund discovery is a client who will treat every discovery as your error.

Is it ever right to rewrite instead of fix?

When there are no tests, no reproducible failures, and the feature set is small enough to rebuild in under the time the audit says the repair will take. Small AI-built apps hit that threshold more often than traditional codebases do, because the feature set is genuinely small.