You post a short job description: "Lovable app, Supabase backend, payments are flaky, need someone to fix it." Three replies come in by evening. One says it's a two-day job. One says the whole thing should be rebuilt. One asks you to send your Supabase login so they can "take a quick look".
Any of the three might be right. You can't tell from the replies, and that's the real problem when you hire a developer to fix a vibe-coded app. The skills that matter here are mostly invisible from a portfolio.
This guide gives you the questions to ask on the call, what a good answer sounds like, which answers end the conversation, and a scorecard you can fill in as you go.
TL;DR
- Vet for diagnosis, not just coding. The developer's first job is to find problems the AI builder hid, such as missing database access rules, leaked keys and payments that don't match your app. Ask them how they'd find those.
- Access and ownership answers matter as much as technical ones. A good hire asks to be invited to your accounts, not given your passwords, and puts code ownership in writing.
- Score every answer Green, Yellow or Red. A Red on security, access or ownership ends the conversation, however good the rest of the call was.
Why vetting for a vibe-coded app is different
Vetting is different here because the job isn't proving someone can build an app — it's proving they can find what's wrong with one they didn't build, and that looks fine on the surface. A normal hiring process asks "can this person build things?" For a vibe-coded app, the better question is "can this person find what's wrong with something they didn't build, and that nobody fully understands?"
The problems are predictable. Veracode tested code from over 100 large language models and found that AI-generated code introduced risky security flaws in 45% of tests (Veracode). In the case behind CVE-2025-48757, a researcher scanned 1,645 Lovable-built apps and found 170 (10.3%) with exposed data across 303 endpoints, including names, phone numbers, payment details and live API keys (bleek.dev). The cause was missing or misconfigured Supabase Row Level Security (RLS).
These problems don't show up in the demo. The app looks fine until a stranger reads someone else's records. So the developer you hire has to be good at looking under the surface, and the interview should test exactly that.
If you haven't yet worked out how bad things are, run our 30-minute fix-or-rebuild self-test first. Your scores make every question below sharper, because you'll know which answers matter most for your app.
Where founders look for help
There are three common routes. None of them is automatically better. Each one fails in its own way.
| Freelance marketplace | Independent freelancer | Small agency or studio | |
|---|---|---|---|
| Best for | One clearly scoped fix | Ongoing work with one trusted person | Audit, fixes and maintenance across several areas |
| Who does the work | Usually the person on the profile | The person you talk to | A team. Ask who exactly |
| Accountability | The platform's dispute process | Your contract and their reputation | Your contract, plus more than one person who knows your code |
| Watch for | Quotes given before anyone has seen the code | One point of failure if they disappear | A senior person on the sales call and a junior on the code |
A practical rule: the less clearly you can describe the problem, the more you need someone who will diagnose before they quote. Marketplaces work well when you can write the fix as one line. If you can't, start with an audit, whichever route you choose.
The interview: 8 questions to ask before you hire a developer to fix a vibe-coded app
Ask these on a call, not by email, so you hear how people think rather than what they can look up. You don't need to judge the technical detail yourself. Listen for specifics, for questions asked back, and for whether they're willing to say "I'd need to look first".
1. "Will you look at the code before you quote?"
Good answer: "Yes. I'd like read access to the repo and database first, then I'll give you a written list of what I found and what I'd fix first." Some charge for this review, some don't. Either is fine, as long as the review happens before the main quote.
Red flag: a firm price, or "you need a rebuild", based on a screen share or your description. Nobody can size a fix to code they haven't read.
2. "How would you check that one user can't see another user's data?"
This is the question behind most vibe-coded app incidents. Supabase's docs say a table in an exposed schema without RLS "is readable and writable by any role with a grant on it" (Supabase RLS).
Good answer: they'd check that RLS is turned on for every table and read each policy against your business rules. They'd also test it by signing in as two different users and trying to open each other's records. Bonus points if they mention Supabase's Security Advisor, which flags issues such as "RLS disabled in public" (Supabase Advisors), and say that it isn't enough on its own.
Red flag: "Lovable's security scan is green, so you're fine." In the CVE-2025-48757 write-up, Superblocks notes the scanner "only flagged the presence of RLS, not whether it worked" (Superblocks).
3. "Where should our secret keys live, and what would you do if one has leaked?"
Good answer: secret keys stay on the server, never in the browser. Lovable's own guidance says secrets in frontend code "should be considered compromised" (Lovable). On a leak, a good developer finds and fixes the cause first, then creates a new key, updates everything, and only then deletes the old one. That's the order Supabase recommends (Supabase API keys).
Red flag: "Just send me the service_role key on WhatsApp." Supabase says a secret key "bypasses every Row Level Security policy you have" (same page). Anyone who handles it casually will handle your users' data the same way.
4. "How do you make sure payments and the app agree?"
Good answer: the app learns about payments from Stripe webhooks rather than from the browser reaching a "success" page. Each webhook's signature is checked, and repeated events are ignored. Stripe warns that without verification "an attacker could send fake webhook events" to grant access, and that endpoints "might occasionally receive the same event more than once" (Stripe webhooks).
Red flag: "The success page upgrades the account, that's standard." It isn't standard. It breaks the moment someone closes the tab.
5. "Who will actually work on the code, and how do you use AI tools?"
Good answer: a named person, plus a clear way of working. Using AI coding tools is normal. What matters is that a human reviews and tests what the tools produce before it ships.
Red flag: "Our team" with no names, or work that gets passed on to people you'll never meet. The opposite is also a warning sign: someone who says AI-built code is worthless and will be thrown away, before they've even read yours.
6. "What access do you need from me, and in whose account?"
Good answer: "Invite me as a collaborator to your GitHub repo, your Supabase org and your Stripe account." Invites keep you in control. On a personal GitHub repo, for example, a collaborator can push code but can't delete the repository or transfer ownership (GitHub permissions). Our handoff prep guide lists everything to get ready before the developer starts.
Red flag: asking for your passwords, or asking you to move the repo into their account "to make things easier".
7. "Who owns the code you write?"
Good answer: "You do. It's in the contract as an assignment of rights." This matters more than most founders realise. Under US law, commissioned work only counts as "work made for hire" if it falls into one of nine listed categories and both sides sign a written agreement saying so (US Copyright Office, Circular 30). Software isn't named on that list, so a clear written assignment is the safer route. The rules differ by country. Ask a lawyer about your own contract.
Red flag: "We'll sort the paperwork later," or a contract that only grants you a licence to use the code.
8. "What does 'done' look like?"
Good answer: a list you could check off. That means written findings, each fix linked to an item on that list, tests or a repeatable check for the risky fixes, and short handover notes so the next person isn't starting from zero. If you have a written spec, share it. A one-page MVP spec gives a good developer something concrete to scope against.
Red flag: "We'll just fix bugs as they come up." That's fine for ongoing maintenance after the first round of fixes. It doesn't work as the first round.
Red flags that end the conversation on their own
Some answers make the rest of the call irrelevant. Stop if the developer:
- Asks for your passwords or wants you to send secret keys over chat or email.
- Quotes a rebuild without reading your code or database.
- Wants the repo, database or domain moved into their account.
- Brushes off exposed data as "fine for an MVP" when you have real users.
- Can't explain in plain English how they'd stop one user seeing another's data.
- Won't put code ownership in writing.
Score the call: Green, Yellow, Red
Use this while you're on the call. It uses the same scoring as the Pass/Warn/Fail checks in our fix-or-rebuild self-test: Green (0), Yellow (1), Red (2).
- Green: a specific answer, and they ask you something useful back.
- Yellow: the right idea, but vague, or "I'd have to check" without saying how they'd check.
- Red: the red-flag answer, or a confident answer that contradicts the official docs.
| Score | Also true | What to do |
|---|---|---|
| 0–3 | No Red anywhere | Strong candidate. Check two references, then agree the audit scope. |
| 4–7 | No Red on Q2, Q3, Q6 or Q7 | Ask them to answer the Yellow questions in writing before you sign. |
| 8–16 | — | Keep looking. |
| Any | A Red on Q2, Q3, Q6 or Q7 | Keep looking, whatever the total. |
These thresholds are our rule of thumb, not an industry standard. The rule that matters is the last row. A charming developer who wants your Supabase password is still a bad hire.
A hypothetical example. Back to the three replies from the opening. Developer A (the "two-day job") answers Q1 with a firm price and Q2 with "the scanner's fine". That's two Reds, one of them on a deal-breaker. Developer B (the "rebuild") hasn't read the code either, so Q1 is Red, but they're solid on Q2 to Q4 and they offer an IP assignment. They score 4–7, so ask why they think a rebuild is needed before trusting the verdict. Developer C (the "send me your login") fails Q6 straight away. None of them is an obvious yes. That's a normal result, and it's the reason to talk to a fourth.
FAQ
Should I pay for a code audit before hiring a developer to fix my app?
Usually, yes. A short, scoped review turns a guess into a list of findings, and you keep the list even if you hire someone else. Our self-test lets you do the first pass for free.
Can the developer who fixes my app keep using Lovable or Bolt?
Yes, if you agree a way of working first. The usual risk is you and the developer changing the same code at the same time, through the builder and through GitHub. Our handoff guide covers how each builder syncs.
Is a freelancer or an agency better for fixing a vibe-coded app?
Neither is better by default. It depends on how clearly you can describe the problem. A freelancer suits one well-defined fix. A team suits a broader audit followed by ongoing work. Score both with the same eight questions.
Next step
If you'd like a second opinion on your app, or want to see how we'd answer these eight questions, Banxal builds and hardens web apps and SaaS products and looks after them afterwards. We'll review the code before we suggest anything, and we'll tell you plainly if a rebuild isn't needed. Tell us about your app.
Which of these questions has caught someone out on one of your hiring calls? Or which one do you wish you'd asked? Tell us in the comments.
Originally published on banxal.com.
Top comments (0)