How to hire a developer to take over your AI-built app

To hire a developer to take over your AI-built app, look for someone who can read code they didn't write, not someone who promises to write more of it. Skip the proposals that could have been sent to anyone. Shortlist the ones that show a live app on your stack and one specific insight about yours. Then start with a small paid audit before you hand over production.

This post is for a founder who built an MVP with Lovable, Bolt, Cursor or Claude and now needs a senior developer to continue. I am one of those developers: I take over apps like yours, and I sell the audit this post recommends. I'll say where that matters, and every check below works on me too.

The AI wrote your code fast. What it rarely does on its own is decide what is safe, test it, and plan for the day something breaks. That is the job you are hiring for.

AI-built apps tend to break in the same few places:

• Database access rules. On Supabase these are Row Level Security policies. A table with only a read policy looks fine in a demo. Then updates and deletes can quietly change zero rows, and inserts fail with an error the generated code often never checks. The user sees "Saved!", and nothing was saved.
• Secret keys in the browser. A key meant for the server ends up in the code every visitor downloads.
• Payments the browser decides. The page marks an order as paid, instead of your server hearing it from Stripe.
• No safety net. No staging copy, no backups you have restored once, no tests.

So the person you want reads first, judges second and writes third. They keep what works, which is most of it. A developer whose first idea is "let's rewrite it from scratch" is offering to throw away the one thing you have that already works, and to bill you for the privilege.

If you are still deciding whether you need a person at all, I wrote about when an AI subscription is enough and when it isn't.

Wherever you post the job (Upwork, LinkedIn, a founder community, a friend of a friend), proposals arrive fast and often look the same. A lot of them are written by AI too, which is a little funny for a job about cleaning up after AI.

Here is what should make you close a proposal before the second paragraph:

• A template placeholder is still in it. A [client name] or a [your project] that nobody filled in. If they didn't read their own message, they won't read your code.
• Your name is wrong, or someone else signed it. It was pasted from the last job, and the one before that.
• It opens by feeling your pain. "I understand how frustrating it is when your app…" That is everyone's opening now. It costs nothing and tells you nothing.
• The diagnosis fits any app. "Your app needs refactoring, a better architecture and performance work." They haven't seen your app. I haven't either, and that sentence is still true of it. It's true of mine too.
• It reads like generated text. Bold headings in a two-paragraph message, emoji bullets, every paragraph the same length, a "Week 1 / Week 2" plan for code they haven't opened. Someone who lets a model write even the hello will let it write your review.
• The rate is far below a senior rate. A senior job at a junior price means the person is not senior, or will not stay. You pay the difference later, in rework.
• It offers free work or a discount. "I'll fix the first bug for free", or a special price just for you. It reads as need, not confidence. And free work comes without a contract, so nothing says the code is yours.
• An agency writes as one person. "I" in the first paragraph, "our team" in the third. Agencies are fine. Hiding who will do the work is not, so ask who writes the code and talk to that person.
• A video link is the whole reply. A short video about your project can be great. A video instead of a written answer means you can't skim it, compare it or forward it to a technical friend.

Good proposals are usually shorter. They show you something instead of telling you something:

• A live app on your stack. A link in the first lines that you can open, built on what you use: Supabase, Next.js, Stripe, whatever yours is. One or two that work beat a list of twenty.
• One specific insight from real work. A sentence a chatbot would not write from your job post. "Check your security rules" is generic. "Your table probably has a read policy and no update policy, so edits do nothing and no error shows" is someone who has been bitten by it.
• An honest gap. "I haven't worked in Lovable itself, but what it exports is React and Supabase, which I know well." A person who admits one gap is easier to believe about everything else.
• A dated, priced first step. "A written audit by Friday, for a fixed price. Read-only access first. Nothing reaches production without staging. You can stop any week." The risk sits on their side of the table, not yours.
• One question only an expert would ask. Everyone asks how many users you have. "Does your Stripe webhook mark an order as paid, or does the page?" or "Do your admins and your customers share one users table?" shows they are already looking at the parts that break.

Count the flags, then:

• Two or more red flags: pass, however good the price looks.
• One red flag: ask about it before you pay for anything.
• No red flags and three or more green ones: offer this candidate a paid first step.
• No red flags, but little proof yet: ask the three questions below.

It's a rule of thumb, not a court ruling. A tired senior can send a clumsy message, and a polished one can come from someone who has never shipped. But the flags are cheap to check, and they sort a long list fast.