Vibe Coding Cleanup: Who to Hire to Finish an AI-Built App
In this article
Quick Answer: Vibe coding cleanup starts with one senior full-stack engineer who reads your whole app before changing any of it, not with a rewrite team. The first jobs are taking ownership of your accounts, locking down who can read and write your data, and adding tests around payments and personal information. Full Scale places dedicated engineers for that work from $35 an hour all-in.
The first person you should bring on board to complete an AI-generated application is a senior developer who reads the entire codebase before making a single change. This means avoiding the code rewriter company, the prompt sorcerer, and the cybersecurity firm that hands over a document and walks away. What you need is one individual capable of identifying the issues in sequence and staying to resolve them.
Your prototype functions. That is the issue. It works so effectively that no one has felt the need to examine the underlying code, and now a real user is on the horizon.
I'm the founder of Full Scale, a service where we provide developers by the month, so I certainly have a vested interest in suggesting you hire someone. Regardless of how much you discount my advice (I will deduct roughly 20%, and I am the one offering this suggestion). In the sections below, all external figures are referenced.
What vibe coding cleanup actually covers
Vibe coding cleanup is anything in an application that wouldn't be visible in a demo, since all that matters for a demo is whether the screen is correct. At Full Scale we divide the parts of an application into these five layers, and AI coding tools consistently leave them thin:
Full Scale's opinion on what an AI-coded app still requires before production users are invited to use it:
| Layer | What AI tools tend to leave behind | What finishing looks like |
|---|---|---|
| Access rules | Database tables readable or writable by anyone with the public key | Every table has rules for who can read and write each row |
| Authentication and secrets | Login that works, with admin pages and API routes left open and API keys sitting in browser code | Every route checks who is calling, and keys live on the server and are rotated once exposed |
| Money and webhooks | Payment code that works on the happy path | Failed payments, duplicate events, and refunds handled and tested |
| Data model | Tables shaped by whatever the last prompt asked for | A schema someone can explain, with backups you have actually restored |
| Tests and monitoring | None, so you hear about outages from customers | Tests on the risky paths and an alert that reaches a human |
It's the top two rows here that can harm people. In 2025, a CVE was issued for the Lovable platform, CVE-2025-48757, describing an insufficient database row-level security policy that permitted remote unauthenticated attackers to read or write arbitrary database tables of generated sites. Lovable disputes the issue. The company claims each customer accepts responsibility for securing the data in their application. This makes sense, and it is the entire lesson. If you own the app, you own the access rules.
It's nothing complicated. According to Supabase's own documentation, a table in an exposed schema without row-level security is readable and writable by any role with a grant on it. You could have an AI tool build you a nice interface over a table that anyone on the internet could read. The demo won't show you that.
Is AI generated code security a model problem you can wait out?
Not even close. Veracode tested over 100 LLMs and discovered that 45% of the code samples failed its security tests. No matter how large or well-trained they were, these LLMs scored about the same on security. This isn't a test of apps built on a certain platform. This is a test of code written by these models. You can interpret this as "the models are not getting safer by themselves," not as a condemnation of any specific platform.
Sitting around and waiting for a new model release to solve your problems is a strategy. It's also a strategy that got us to this point.
Take ownership before anyone touches the code
This first item is not about the code. Make sure the company is the owner of the domain, the repo, the host, the DB, and the payment account. Don't make it one person's login. I would not skip this one. Full Scale's 2026 field report, AI Built It. Who Owns It?, based on 12 founder/tech leader interviews in Aug/Sep 2026, highlights one founder who spent a year untangling a platform "held hostage" by a domain a former developer owned. The report presents that as the founder's own account, and we did not see it happen.
Do this on day one, before you hire anyone:
- Transfer the domain and DNS to a company-owned account with two admins.
- Put the code into a repo under a company organization, not a personal user.
- Rotate all API keys and DB passwords that were ever stored in a chat window, screenshot, or the browser code.
- Verify you can restore the DB from a backup (because "we have backups" and "we have restored a backup" are different sentences).
If you plan to hire any external engineers, this same checklist applies to them. No one outside of your company should hold the sole keys to any of it, including us.
Who to hire to finish an AI-built app
Hire one senior full-stack engineer first, and only expand the team after that engineer has told you what the app actually needs. Who you should hire depends on your current situation, so below is how Full Scale recommends categorizing each scenario.
Full Scale's guide to who to hire, by situation:
| Your situation | Who to hire | Why |
|---|---|---|
| Working app, paying users, a roadmap for the next year | One dedicated senior full-stack engineer, adding a second after the audit | The person who learns the codebase keeps working on it |
| One known problem with a clear end, such as a payment integration | A freelancer from a marketplace | Cheaper and faster than a long-term hire for a job with an end date |
| App handles health, payment card, or financial data | A senior engineer plus an outside security review | A second set of eyes on the layer that regulators care about |
| Nobody can explain how the app is structured, and it is small | A senior engineer to decide between refactoring and rewriting | Sometimes a clean rebuild of a small app is the cheaper path |
| Prototype still in testing with no customers | Nobody yet | Keep prototyping and read what AI prototyping tools are good for |
Notice what is not in the table: a "vibe coding specialist." A vibe coding developer is simply a developer who understands when they should not trust the output.
In a post about why developer flow state turned into a babysitting job, I wrote that vibe coding "only works if you've been coding long enough to know when the AI is wrong." That sentence, transformed into a job description, is the hire you need.
Full Scale's field report also heard the same thing from the buyers. One founder told us, "I can just do what Claude tells me, but then I don't know. I need another set of eyes to say this migration was successful and it has high integrity." Another said, "We have a backlog of prototypes that are vetted with customers. We just can't get them to production fast enough." Our reading of those calls is that the last mile (architecture, data, tests, and security) is where the staffing gap sits.
How to tell a real fix from a vibe-coded fix of vibe code
The way to filter for that is easy: put your own repo up in front of the candidate and ask them to read through it aloud. You want someone who spots the open table, the unmasked secret, and the missing check on the admin route during the first hour. You don't want someone eager to start refactoring without having even looked at the code yet; that's a red flag that they're trying to sell you a bigger job.
Here are three things to be wary of:
- They try to fix issues using the same approach that introduced them. Relying on AI to speed up development is standard practice now, but feeding each bug report into an AI tool and then deploying the results is the reason we're in this situation.
- They attempt to provide a cost estimate before reviewing the source code. Think of a prototype as a stage prop. From a distance it appears to be a house, and estimating the cost of the house is just speculation until you pull back a panel.
- They're unable to specify what will remain untouched. A competent engineer tasked with completing an AI-generated application will inform you of which modules are sound and need not be altered, saving you unnecessary expense.
I have a line about my own code, "My code sucks. The good news is that my code is not going to production!" A prototype isn't afforded that luxury. Either it's already deployed or it soon will be, which is precisely the reason someone needs to audit it.
For the interview itself, see Full Scale's post on how to interview a software engineer in the AI era and their piece on the skills assessment we use instead of trivia. The tone to listen for in a candidate is straightforward: identify the issue, determine its priority for resolution, and recognize what requires no intervention.
What the first thirty days should look like
There is a correct first month, and there is an incorrect first month, and the order is critical. Full Scale proposes the following order, and this is guidance, not a guarantee for your specific case.
- Week one: Read and lock down. The engineer reads the codebase, closes the permissions and exposed credentials, and documents their findings. The result should be a short non-technical priority list, ranked by how badly each item can hurt you.
- Week two: Protect money and personal data. There is test coverage over payment flows, registration, and all things that touch personal information. Alerting is configured to notify a human of outages.
- Weeks three and four: Decide structure. Only at this point does the decision about keeping or replacing parts of the codebase begin to be made, using the audit as an input. If the engineer suggests replacing everything on day two, that is a flag.
- After that: Ship the roadmap. The same person who did the cleanup begins shipping new features on a codebase they now understand.
Do not do any of this later. Technical debt from a prototype is technical debt just like any other, and it compounds the same way, only faster, because no one documented why any of it works.
Where a dedicated Philippines engineer fits
When the AI-built app is going to be the first version of a product that continues to grow and change, a dedicated engineer from Full Scale fits. Full Scale puts senior engineers from the Philippines through staff augmentation: they join your team full-time, work your hours, and stay on your product.
Here's what Full Scale's terms look like, so you can do the math. Developers start at $35 per hour all-in (the floor, and not a flat rate; it depends on seniority and skill), with a two-week money-back guarantee so your rough estimate for the first two weeks will be $0. After that, you're not locked into a long-term contract, and you can let a developer go with 30 days' notice. You can start in as little as 7 days (depending on who is available on the bench), and getting fully up to speed on your codebase takes longer. You can see the details on our pricing page, and my post on what happens when a developer isn't working out spells out the rest of the terms in plain English.
The honest truth is that there's one limitation: If you just need a specific, clearly scoped fix with a defined end date, a freelance marketplace will be quicker and cheaper than we are, and you should use one. Our approach is the right fit when there's a road map after the cleanup. If you're thinking about dedicated developer vs. finding savings elsewhere, you should learn about cheapshoring first. I made up that term for hiring the cheapest developer you can find, and it's the surest way to turn a rescue into a second rescue.
But if you're still trying to figure out what to build and for whom, that's another problem altogether. My book, Product Driven, is about the chasm between "we built it" and "it is actually a product," while this guide for non-technical founders addresses those earlier decisions. If the app already exists and needs an owner, book a call.
Frequently asked questions
What is vibe coding cleanup?
Vibe coding cleanup is the work of taking an app built mostly by AI tools such as Lovable, Bolt, v0, or Cursor and making it safe and maintainable enough for real customers. Full Scale treats it as five jobs in order: take ownership of every account, audit access rules and secrets, fix the data model, add tests and monitoring, then build the roadmap on top.
How do I fix AI generated code that works but I don't trust?
Start by having a senior engineer read it before anyone changes it. Fix who can read and write your data first, then add tests around the parts that handle money and personal information, and only then refactor. Full Scale recommends against a full rewrite until that review says the structure itself is the problem.
Do I need a vibe coding developer or a regular software engineer?
You need a regular senior software engineer who is comfortable with AI tools, not someone whose only skill is prompting them. Full Scale looks for someone who can explain why a piece of generated code is wrong, because that skill is what finishing an AI-built app actually requires.
Is AI generated code secure enough for production?
Not by default. Veracode's 2025 report found 45 percent of the AI-generated code samples it tested failed a security check, and the result did not improve with larger models. Treat generated code as an unreviewed draft until someone has checked authentication, access rules, and secrets.
Can Full Scale finish my AI-built app?
Full Scale places dedicated senior engineers from the Philippines who join your team and stay on the product, starting at $35 an hour all-in, with a two-week money-back guarantee. That fits an app with real users and a roadmap. A single fix with a clear end date is cheaper through a freelance marketplace.
