How do I find and hire the right developer to fix my AI-built app?

The hard part of this is not finding developers. There are plenty. The hard part is that you are being asked to evaluate work you cannot evaluate, and to compare quotes from people who cannot honestly produce a quote without looking at the thing first.

That is genuinely a difficult buying problem, and most of the bad outcomes I hear about are not caused by bad developers. They are caused by a process that forced both sides to guess.

Why this hire is harder than a normal one

Three things stack up.

You cannot assess the deliverable. If you hire a designer you can look at their work and have an opinion. Code offers you nothing — it either runs or it does not, and it ran before you hired anyone. The things you are paying to have fixed are specifically the things that are invisible when they are working and invisible when they are broken.

The candidate cannot quote accurately either. An AI-built app is a genuinely unknown quantity from the outside. Two apps that look identical in a demo can be a week apart in repair work, depending on what is behind them. Anyone giving you a confident number without looking is either padding heavily or about to discover something and have an awkward conversation with you.

And the market has not caught up. "Fix my AI-built app" is a specific competence — knowing exactly which twelve things to check and in what order — and it does not yet map onto a job title. Plenty of excellent engineers have never seen this particular failure pattern.

The fix for all three is the same, and it is a sequencing fix.

Buy a review before you buy a build

Do not start by asking for quotes to fix your app. Start by paying a small, fixed, bounded amount for someone to look at it and write down what they found.

This solves both sides of the problem at once. You get a deliverable you can actually judge — a written document, in language you can read, describing your app — which is a far better test of someone than a portfolio. They get to see the code before committing to a number, which means the number they eventually give you is real. And if it goes badly, you have spent a few hundred and learned something, rather than being three weeks into a project with someone you do not trust.

It also reveals the thing you most need to know, which is how they think when they are being paid to be careful.

What a good review contains: what the app is and what it is built on, what a user can reach that they should not be able to, what happens on the failure paths, what the plan limits are against actual usage, what would happen if it broke at 3am, what it would take to change something safely, and a prioritised list with an honest cost against each item. Roughly the shape of my own Production-Ready Audit, and roughly what any competent equivalent should look like.

What it should not contain: a recommendation to rebuild, delivered before any of the above.

The strongest filter is what they say before they look

If you take one thing from this post, take this.

Watch what a candidate says in the first conversation, before they have seen a line of your code. The person who opens with "AI-generated code is a mess, you really need this rebuilt properly" has told you something important, and it is not about your app — they have not read your app. They have told you their default, and their default is the most expensive option available.

Rebuilding is sometimes right. There are honest cases, mostly a data model that is wrong at the root or a platform you cannot buy your way past, and I have written about how to tell the difference. But the case has to be made after looking, about your specific situation, in a sentence you can understand.

The good version of that first conversation sounds different. It sounds like questions: what does the app do, who uses it, how many, is money involved, whose data is in it, what have you noticed going wrong. Someone establishing consequences before proposing solutions.

Five questions worth asking

"What would you check first, and why that?" You are listening for a specific order with reasoning attached — access control before performance, say, because one leaks and the other annoys. A generic answer about best practices means they do not have a routine for this.

"How would you test whether one customer can see another's data?" The correct answer involves a second account. Someone who describes actually logging in as a different user and trying to reach records that are not theirs is describing the real test. Someone who talks about reviewing the code is describing something much weaker.

"What will you not be doing?" Good practitioners are quick to draw the boundary — this covers the backend and not the design, this covers security and not a performance rewrite. Reluctance to name the boundary is how scope disputes are born.

"What will I have at the end that I do not have now?" The answer should include artefacts, not just outcomes: a document, a repository under your control, a list, a handover. If the only deliverable is "it will be fixed", you have no way to tell when it is.

"What happens if you find it is worse than expected?" There is a good answer to this — that they will stop, tell you, and re-scope before continuing — and a bad one, which is silence followed by an invoice.

Red flags, in rough order of how much they should worry you

Rebuild before reading. Covered above. The most common and most expensive.

Wanting owner access to your accounts under their own email. Collaborator access is normal and necessary. Being the account owner is not, and this is the single most common way people end up unable to reach their own infrastructure after a relationship ends.

No written anything. If everything is verbal — the scope, the findings, the plan — there is nothing to compare against later, and disagreements become memory contests.

Explanations that need a translator. A person who understands a problem can say what it is and what it would cause in ordinary sentences. Persistent jargon in a conversation with a non-technical client is either a communication problem or a cover.

Open-ended hourly with no scope, on an app nobody has assessed. This is the arrangement most likely to produce a bad outcome, and it produces bad outcomes for the developer too.

Dismissiveness about the AI. Partly because it is unpleasant, but mostly because it correlates with wanting to throw the whole thing away. The tool built something that works and has users. That is not nothing.

Green flags

Someone who asks what happens to your business if the app is down for a day. Someone who asks whether money and other people's data are involved before asking anything technical. Someone who volunteers what they are not sure about. Someone who proposes a small first piece of work rather than the whole thing. Someone who explains a problem and then says how serious it actually is, including when the answer is "not very".

And one that is easy to miss: someone who tells you a part of it is fine. The instinct to find fault everywhere is a sales instinct. An honest review has "this is already correct" in it.

About rates

I will be brief here because I think rate is the least important variable, and because most published figures are less useful than they look.

The only broad recent survey I would cite at all found an average around one hundred euros an hour across more than five thousand freelancers — but that is all freelance disciplines pooled together across German-speaking Europe, not a backend rate, and I would not use it to judge a specific quote. The large recruitment firms publish permanent starting salaries rather than freelance rates, which is a different thing again.

What actually determines your cost is not the hourly number. It is whether the work is bounded. A defined list of items at a fixed price from a more expensive person routinely comes in under an open-ended hourly engagement with a cheaper one, because the second arrangement has no natural end. The real cost picture, including the infrastructure you will be paying for either way, is worth reading before you set a budget.

The contract terms that actually matter

Not the intellectual property boilerplate, which is usually fine and usually copied from a template. These:

The repository lives under your account or organisation. They get access to it. It does not live under theirs.

Hosting, database and every third-party service are under your billing. This is the one people regret. Services set up under a developer's account, on a developer's card, become a hostage situation nobody intended.

Every secret is handed to you in writing at the end. API keys, service credentials, anything they created on your behalf. Ask for the list explicitly, because it will not appear on its own.

A written handover. What was changed, what was not, what is still outstanding, and what you should do next. A page is enough. This is also the document that makes the next person cheap instead of expensive.

Something ships every week or two. Not necessarily a feature — a fix, a report, a deployed change. The failure mode of a month with no visible output is not usually dishonesty, it is drift, and short cycles catch it early.

How to run it once it starts

Ask for the written findings before any repair work begins, and read them. Pick what gets fixed first yourself, based on your business rather than their interest — if you take payments, the money path comes before the tidy-up. Ask, at each item, "how would we know this is fixed?" and expect a concrete answer. And ask to be shown the app breaking on purpose at least once — an attempt to reach another account's data that now fails is worth more reassurance than any amount of description.

If you would rather just start with the review

That is what I do, and I would rather you had it from anyone competent than not at all.

The Production-Ready Audit is exactly the deliverable described above: your access boundary tested from a second account, the failure paths walked, your plan limits checked against real usage, what you actually own written down, and a prioritised fix list with honest costs. From $499, back in five to seven days. Fixed scope, one document, no obligation to hire me for whatever it finds — and I will say so plainly if the answer is that your app is in better shape than you feared.

If you are not yet sure you need anyone, that question deserves a straight answer too. And the underlying list of what usually needs fixing is in the ten problems every AI-built app has in production.