An agency's guide to inheriting a client's vibe-coded app

A client shows up with an app they built themselves in Lovable or Bolt. It works, sort of. They want you to take it over, add features, and keep it running. You say yes, and three weeks later you’re firefighting a data leak nobody warned you about.

The problem isn’t the AI code. It’s saying yes before you know what you’re inheriting. Here’s how to run the assessment before you sign anything.

Do a paid discovery before you quote the build

The biggest mistake agencies make with these projects is quoting a fixed price for “take over and improve the app” based on a demo. You’re not pricing a feature. You’re pricing an unknown amount of hidden cleanup. Charge for a short discovery first, deliver a written report, and quote the real work from there. A day or two of paid discovery protects you from a fixed-price death march.

The inheritance checklist

Work through this before you commit to owning the thing.

Access and ownership

• Do you have the actual source code, or just access to the builder’s dashboard? If you can’t export the code, you can’t properly maintain it.
• Who owns the domain? Get it moved into an account the client controls, not the freelancer’s personal account or a builder’s default subdomain.
• Who owns the accounts for the database, email provider, payment provider, and hosting? Chase down every login. Orphaned accounts under a former contractor’s email are a time bomb.

Data safety

• Are there backups? When was the last successful test restore? If the answer is “the platform does it,” find out how long they keep them and whether anyone has ever restored one.
• Is the database exportable? You want a plain SQL dump you can move, not data trapped behind a proprietary API.

Security

• Scan for secrets committed in the code. AI tools routinely paste API keys and database passwords into files. Assume they’re there until you’ve checked.
• Check whether the database has row-level security. Many AI-built apps ship with a database that lets any logged-in user read any other user’s records. Test it: log in as user A, try to load user B’s data by changing an ID. If it works, that’s a reportable breach waiting to happen.
• Look at CORS, rate limiting, and whether debug mode is on in production.

How it runs

• Where is it hosted, and what does that cost per month today? What does it cost at 10x the users?
• Are there database connection limits that will fall over on a traffic spike?
• Is there any monitoring? Will you know it’s down before the client’s customers do?

Legal

• If the app handles EU users’ data, is there a data processing agreement in place, and does the client know they’re the data controller? You don’t want to inherit GDPR exposure silently.

Turn the checklist into a client conversation

Your report should sort findings into three buckets so a non-technical client can act on it.

• Must fix before we add anything: exposed secrets, users able to read each other’s data, no backups. These are stop-the-line items.
• Fix soon: no monitoring, connection limits, missing data processing agreement.
• Improve over time: code structure, test coverage, performance tuning.

This does two things. It protects you, because now the client has agreed in writing that the app arrived with these problems. And it usually unlocks a bigger, cleaner engagement than “add this one feature,” because the client finally understands the state of what they built.

Price the ongoing risk, not just the build

If you’re going to host and run this app, someone is now on the hook when it breaks at 2am. That’s an operations cost, not a build cost, and it doesn’t stop. Either price a monthly retainer that covers backups, monitoring, updates, and incident response, or hand that piece to someone who does it as a product. Don’t absorb 24/7 responsibility inside a fixed project fee and hope it never gets called on.

Or, we do it for you

If you’d rather not own the hosting and on-call burden, we run the production layer so you can focus on features. Point us at the client’s app and we’ll send you a written audit of exactly what you’re inheriting, in language you can forward straight to the client.

FAQ

Should I rebuild the app from scratch or work with what’s there?

Usually work with what’s there first. A rebuild is expensive and delays value, and the existing app already proves people want it. Stabilize it, fix the red items, then refactor the worst parts over time. Only rebuild if the data model is genuinely unworkable, and even then, migrate the data rather than throwing it away.

The client thinks their app is basically done. How do I manage that?

Show, don’t tell. Run the “can user A see user B’s data” test in front of them, or show them the API key sitting in plain text in the code. A concrete demonstration lands harder than a warning. Once they’ve seen one real problem, they trust your assessment of the rest.

How do I price a takeover when I don’t know what’s inside yet?

Don’t. Charge for discovery, deliver the written report, then quote the fix and the build from real findings. Fixed-price quotes on unseen AI code are how agencies lose money on these projects.

What’s the fastest red flag to check first?

Exposed secrets and cross-user data access. Both are common in AI-built apps, both are serious, and both can be checked in under an hour. If either is present, you’ve already justified the discovery fee.