Skip to content
← Back to the blog
software developmentproduct

How to hire a developer to fix your vibe-coded app

What to ask a developer before they touch your Lovable, Bolt or Cursor app, red flags to walk away from, and what to share or never share when giving access.

By Devonauts Team6 min read
Leer en español →
A person on a video call with a woman shown on the laptop screen

To hire a developer to fix an app you built with Lovable, Bolt, v0, Replit or Cursor, look for someone who reviews the code before quoting, gives you a written price or a capped estimate, works in your own repository and accounts, and explains what they changed in plain language. Give access by inviting them with their own account, never by sending passwords or secret keys. Walk away from anyone who asks for your passwords, wants to rewrite everything before looking, or can't explain the problem back to you.

This guide gives you the questions to ask, the red flags, and a clear list of what to share and what to keep to yourself.

What kind of developer do you need?

The tool you used matters less than the technology underneath it. Most AI-built apps are React or Next.js on the front end, with Supabase (a Postgres database with built-in login), Firebase or a similar backend behind it, and often Stripe for payments. Look for someone who has worked with those pieces.

You'll usually choose between three options:

  • A freelancer. Often the most flexible. Quality varies a lot, so the questions below matter more.
  • An agency or studio. More people and process. Some will want to rebuild your app in their preferred stack.
  • A team that specializes in AI-built apps. They see the same problems every week (permissions, payments, deployment) and are used to working with code that came out of a prompt.

Whichever you choose, the same checks apply.

What should you ask before you hire anyone?

Send these questions before any work starts. Good developers answer them easily.

  1. Have you worked on apps built with Lovable, Bolt, v0, Replit or Cursor? You want someone comfortable with code they didn't write and that has some rough edges.
  2. Will you look at the code before giving me a price? A quote based only on screenshots is a guess.
  3. What exactly will you deliver? A fixed list of outcomes, such as "users can only see their own orders", is easier to check than "general improvements".
  4. Is the price fixed, or hourly with a cap? Either can be fine. What you want to avoid is an open-ended hourly rate with no ceiling.
  5. Will you work in my repository, with commits I can see? You should always be able to see what changed and keep working if they disappear.
  6. How will you protect my data while you work? Listen for "backup first", "test on a copy" and "small changes".
  7. How will you test the fix? For permissions, they should mention testing with more than one account. For payments, testing in Stripe's test mode first.
  8. Who owns the code? You do. Get that in writing if there's any doubt.
  9. Will I be able to keep building with my AI tool afterwards? The answer should be yes.
  10. How fast do you reply, and how do we communicate? Agree on it upfront.

What are the red flags?

Any one of these is a reason to slow down. Two or more is a reason to look elsewhere.

  • They ask for your passwords, two-factor codes or secret keys. A competent developer asks to be invited.
  • They want to rewrite the whole app before they've looked at it. Sometimes a rewrite is right, but nobody can know that without reading the code.
  • No written scope or price. "We'll see how it goes" usually goes over budget.
  • They want to move your app to their own accounts or servers without a clear reason and a plan to give it back. Your app, your data and your domain should stay in accounts you own.
  • They promise your app will be "100% secure". Nobody can honestly promise that. They can promise to find and fix specific problems.
  • They change things directly on the live app without a backup.
  • They can't explain the problem in words you understand. If they can't explain it, you can't judge whether it was fixed.
  • They push you to decide today.

What should you share, and how?

Share access by invitation, with the smallest permissions that let them do the job. That way you can see who did what and remove access in one click.

WhatHow to share it
A link to the appThe live address and, if different, the preview
A test loginCreate an account with fake data for them. Don't share your personal account.
The codeConnect the project to GitHub and invite them as a collaborator on the repository
The backendInvite them to your Supabase organization (or Firebase project) as a member, with the lowest role that's enough
HostingInvite them to your Vercel, Netlify or Render team
PaymentsStripe lets you invite team members with limited roles, such as Developer or View only
The builder projectIf Lovable, Bolt or your tool lets you invite collaborators, use that
The problemA short written description, steps to reproduce, screenshots and console errors

Our post on when to bring in a developer has a template for describing the problem, and finding what broke in your app shows how to collect the errors.

What should you never share?

  • Passwords to any of your accounts, including your email, Lovable, Bolt, GitHub, Supabase or Stripe login.
  • Two-factor authentication codes. Anyone who asks for one is trying to log in as you.
  • Secret keys by chat or email, such as the Supabase service_role key or a Stripe secret key. If a developer needs one for a server, they can set it in the platform's secrets settings through their own invited access.
  • Exports of real customer data, unless it's truly needed, agreed in writing and handled carefully. Test data is almost always enough.

If something was shared by mistake, rotate it (create a new key and revoke the old one) once the work is done.

What should happen while they work?

  1. Stop prompting the AI on the same project. Two sets of changes at once create conflicts you'll pay to untangle.
  2. Agree on check-ins. A short update when they find the cause, and another when the fix is ready.
  3. Ask for a written summary at the end: what was wrong, what they changed, how they tested it, and what to watch for next time you prompt the AI.

What should you do when the work is done?

  1. Test the fix yourself, using the same steps that showed the problem.
  2. Remove their access from GitHub, your backend, hosting and Stripe, unless you're keeping them on.
  3. Rotate any key they could see, if you're unsure how it was handled.
  4. Save the summary. It's useful the next time something breaks.

How does this work with Devonauts?

We start with a diagnosis. The free App Health Check looks at what your app exposes from the outside. The App Rescue Audit ($299, one-off) is a code review by a senior engineer with a written report in 2 business days; if it finds no medium or high severity issue, you get a full refund, and if you start a plan within 30 days, the $299 is credited to your first month.

Fixes get a fixed price you approve before we touch anything. We ask for repository access in whatever way you're comfortable with, and you can revoke it anytime. For ongoing help there's Care at $249 a month, Care Plus at $749 a month, and the Dev Subscription at $2,900 a month. A person replies within one business day. Details are on our pricing page.

Quick answers

Should I hire someone who only knows the AI tool, or a general developer? A developer who knows the underlying stack (React, Next.js, Supabase, Stripe) is what you need. Familiarity with AI-built code is a plus.

How much will it cost? It depends on the problem more than the tool. We break it down in how much it costs to fix an app built with AI.

Do I need an NDA? If your idea or data is sensitive, ask for one. Most professionals are used to signing them.

Ready to get help?

See how our AI app rescue works, or go straight to our pages for Lovable, Bolt, Cursor, Replit and v0 apps. When you're ready, send us your app's link and a short description.

Still stuck with your app?

Run the free health check on your app's URL, or get the $299 App Rescue Audit: a senior engineer reviews the code and sends you a written report in 2 business days.