DEV Community: Manveer

Hand Off a Lovable or Bolt App to a Developer: Prep Guide

Manveer — Thu, 01 Oct 2026 21:14:32 +0000

You built the app in Lovable or Bolt. Now you've found a developer or agency to take it further, and their first message is: "Can you send me access?"

Before you reply, work out what "access" means. A Lovable or Bolt app lives in several places: the builder, a GitHub repo, a database, a secrets store, a domain, plus payment and email accounts. Hand off a Lovable app to a developer without mapping those, and either they spend their first paid days finding your setup, or you hand over keys you can't take back.

This guide covers the founder's side: what to export, lock down and write down before a developer opens the repo.

TL;DR

Give access, keep ownership. Invite the developer into your GitHub, database and hosting accounts. Don't transfer the accounts themselves unless you're selling the app.
Find your backend first. Lovable Cloud, your own Supabase project and Bolt Database each hand off differently. Neither builder offers a one-click way to move off its built-in database.
Secrets don't travel with the code. Lovable secrets are write-only and never sync to GitHub. Make a list of every key, share the keys safely and rotate any that have been pasted into chats.

Why handoff prep matters

Developers bill for discovery: an hour spent asking "which Supabase project is production?" costs the same as an hour building features.

There's a security reason too: Lovable's own guidance says "secrets stored in frontend code are visible to users and should be considered compromised" (Lovable security best practices) — a key pasted into a prompt, Slack thread or freelancer email counts the same way.

What moves automatically vs what you must export

The biggest variable is where your data lives — find out first.

Lovable Cloud. This is Lovable's built-in backend, "built on Supabase's open-source foundation" (Lovable Cloud docs). You manage it inside Lovable. We found no documented way to give an outside developer direct access to the dashboard underneath it.
Your own Supabase project connected to Lovable. Lovable says this route gives you "your own Supabase account and billing, full access to the Supabase dashboard" (Lovable Supabase docs).
Bolt Database. Bolt "will typically automatically create one as soon as your project needs it" (Bolt databases intro). On Pro or Teams plans you can claim it into your own Supabase organisation (Bolt Supabase docs).

Item	Lovable + Lovable Cloud	Lovable + your own Supabase	Bolt + Bolt Database
Code	Two-way GitHub sync, one branch at a time	Same	GitHub sync with auto-commits, or ZIP download
Database	Export data and storage; no one-click move to your own Supabase	Already yours; invite the developer to your Supabase org	Claim into Supabase (Pro/Teams) for direct access
Secrets	Write-only, not synced to GitHub	Lovable secrets plus any Supabase-side keys	In Bolt's Secrets panel; unclear if included in exports
Custom domain	Via Lovable: belongs to the workspace. External: A + TXT at your registrar	Same	Check where you bought it
Stripe, email, analytics	Never moves; lives in your own accounts	Same	Same

Lovable states "there is no one-click migration from the built-in backend (Cloud) to Supabase or the other way" (Lovable Supabase docs), and Cloud's region can't be changed once enabled (Lovable Cloud docs). Treat a move to your own Supabase as a scoped migration, not a settings change.

The pre-handoff checklist: access, code, data, docs

Work through this in one sitting; most of it takes a couple of hours and needs no technical skill.

Access

[ ] Write down every account the app touches: builder, GitHub, database, hosting, domain registrar, DNS, Stripe, email provider, analytics and any AI API. Note the login email and who pays for each one.
[ ] Turn on two-factor authentication for every account you own.
[ ] Invite the developer as a member or collaborator, not an owner. Supabase project transfers require you to be the source org's owner and can lower people's roles (Supabase project transfer). Keep the project in your org and add the developer to it.
[ ] Choose a safe channel for sharing keys, such as a password manager's shared vault. Don't use email, and don't use a chat app that keeps history forever.

Code

[ ] Connect GitHub if you haven't, and make sure the repo is in an account or organisation you control.
[ ] Confirm which branch the builder syncs to. Lovable "only edits and syncs one branch at a time" (Lovable GitHub docs).
[ ] Download a ZIP snapshot of the code today and keep it outside the builder.

Data

[ ] Take a backup before anyone touches anything. On a Supabase project you control, the CLI can dump roles, schema and data as separate files:

supabase db dump --db-url "$DB_URL" -f roles.sql --role-only
supabase db dump --db-url "$DB_URL" -f schema.sql
supabase db dump --db-url "$DB_URL" -f data.sql --use-copy --data-only

(Supabase backup and restore. The full data command in the docs also excludes two storage tables. Copy it from there.) On Lovable Cloud, use the export option the Cloud docs describe for the database and storage files.

[ ] List which tables hold personal or payment data.

Docs

[ ] Write a one-page "how it works": who the users are, the three most important flows (signup, the core action, payment), and what's broken.
[ ] List every integration and which secret it uses, without writing the secret values in the doc.
[ ] Note anything you set up outside the builder, such as Stripe webhooks, DNS records or cron jobs.

How to hand off a Lovable app to a developer: Lovable-specific steps

Decide between collaborator access and moving the project. You can share the project, move it to another workspace, or transfer ownership; the new owner needs the owner, admin or editor role (Lovable project settings). For a normal engagement, share access and keep ownership.

Be careful moving workspaces once GitHub is connected. Moving the project to another workspace breaks the GitHub connection, and reconnecting creates a new repository; disconnecting works the same way (Lovable GitHub docs). Moving the repo itself is safer: sync continues "when your Lovable workspace also has a GitHub connection for the new owner," and GitHub keeps issues and collaborators and redirects the old URL (GitHub: transferring a repository).

Agree who edits where. Pushes to the active branch flow back into Lovable, so don't prompt on that same branch while the developer is working.

Rebuild your secrets inventory by hand. Lovable secrets "are write-only: after you save a secret, its value can never be viewed again in Lovable, only replaced or deleted," and they don't sync to GitHub (Lovable Secrets docs). If the original key isn't saved anywhere, generate a new one from the provider. The .env file is different: Lovable commits it so build-time VITE_* values are available, so it must hold only public values.

Check your domain. Domains bought through Lovable "belong to your workspace, not to a single project," and transferring one out is irreversible from Lovable's side (Lovable custom domain docs). An outside domain just needs an A record and a _lovable TXT record at your registrar — make sure you, not a past freelancer, can log in there.

Bolt app developer handover: Bolt-specific steps

Export to GitHub. Bolt's GitHub integration creates a commit "every time you make a change that doesn't break the project," and "checks GitHub every 30 seconds for any updates made outside Bolt" (Bolt GitHub docs). Only the project owner can manage it, and disconnecting is permanent — "you can't manually reconnect it" — so don't disconnect to "clean things up" before a handoff.

Keep a ZIP as well. Use Export > Download from the project title menu (Bolt projects docs) for a dated snapshot you control.

Don't transfer to a user unless you mean it. Bolt lets you transfer a project to another user, but "after the recipient accepts the transfer, you won't be able to access the project or make any further edits" (same page) — that fits a sale, not hiring a contractor.

Handle the database before you change anything. To get the developer into a real Supabase dashboard, claim the Bolt database into your Supabase organisation (requires a Pro or Teams plan and Supabase org owner). Don't connect a new Supabase project instead: Bolt warns that doing so "will replace the connection, which may cause data loss" (Bolt Supabase docs).

Treat secrets as unknown until checked. Bolt's Secrets panel keeps values out of users' browsers (Bolt secrets docs), but Bolt's docs don't say whether secrets or .env files end up in GitHub syncs or ZIP downloads. Open both and check — rotate any private key you find.

What a developer checks in the first hour

A good developer runs roughly these checks first — here's what each finding means.

First-hour check	Good sign	Bad sign and what it means
Clone and run the repo locally?	Runs from the README	Fails: expect setup cost before feature work
Secret keys in the browser bundle	Only publishable keys	A Supabase secret or `service_role` key: rotate it today — secret keys "bypass Row Level Security" (Supabase API keys)
Row Level Security on user tables	On, with policies per table	Off: any logged-in user may read others' data
Which environment is production?	One clear prod project	Several near-identical projects to untangle
Payment webhooks	Signed, handled server-side	Missing: payments can succeed without the app knowing

If they find a leaked key, follow Supabase's order: "Fix the root cause of the leak before you rotate anything," then create the new key, update everywhere, and retire the old one (Supabase API keys) — rotating first just leaks the new key too.

Handoff or rebuild?

Most apps that reach a handoff need fixing, not replacing. The deciding question is the data model, not the code: if your database still describes how your business works, a developer can harden what you have; if it doesn't, every fix fights the structure underneath. Run that test — Fix or Rebuild Your Vibe-Coded App? A 30-Minute Self-Test — before the handoff.

FAQ

Can I export a Lovable app to GitHub and keep building in Lovable?
Yes. The sync is two-way on one active branch. Lovable can export to a new repo but can't import an existing one (Lovable GitHub docs).

Should I give my developer my Lovable or Bolt login?
No. Invite them under their own accounts to the project, GitHub and Supabase — shared logins make it impossible to later remove just one person's access.

Do I need to move off Lovable Cloud before a handoff?
Not necessarily — only if the developer needs direct database access. It's a manual job, though: export the data, connect a Supabase project and rebuild the schema (Lovable Cloud docs).

When should I rotate secrets?
Rotate any key pasted into a chat, email or prompt before the handoff, and rotate every key the developer had when the engagement ends.

Next step

Want a second opinion before committing budget? Banxal's development services include a handoff review: we go through your repo, backend and secrets and tell you plainly whether it needs fixing, hardening or a partial rebuild. Get in touch and tell us what you've built.

Originally published on banxal.com.

Fix or Rebuild Your Vibe-Coded App? A 30-Minute Self-Test

Manveer — Thu, 01 Oct 2026 19:57:39 +0000

Your Lovable, Bolt or Cursor prototype has real users. It also breaks every week, and you're about to pay someone to sort it out. Before you do, you need to know whether to fix or rebuild your vibe-coded app, because the answer decides whether you're buying a few days of work or a few months.

Most guides end with "book an audit". This one gives you the audit's first pass free: eight checks, about 30 minutes, no developer needed, ending in a verdict.

TL;DR

Most vibe-coded apps need fixing, not rebuilding. The usual problems are exposed secrets, missing database access rules and fragile payment handling. Each of those can be fixed on its own.
Your data model decides whether you rebuild. If your database can't describe how your business works today, patching the screens won't help.
Run the 8 checks below on your own app. Score them, read off your verdict, and give the results to whoever you hire so you aren't paying them to discover what you already know.

Why vibe-coded apps work in the demo and break with users

AI builders are good at getting a screen to show the right thing. Production needs more than that. Strangers have to be kept out of each other's data. Payments have to keep working when someone closes the tab mid-checkout. A table with 50,000 rows has to load as fast as it did with five.

Security research shows how big the gap is. Veracode tested code from over 100 large language models and found that AI-generated code introduced risky security flaws in 45% of tests (Veracode GenAI Code Security Report). The best-known example is CVE-2025-48757. A researcher scanned 1,645 Lovable-built apps and found 170 (10.3%) with exposed databases across 303 vulnerable endpoints. The leaked data included emails, phone numbers, payment status and API keys (bleek.dev, Superblocks). The cause was missing or weak Row Level Security, which is check 2 below.

None of this means your app is doomed. The demo proved demand. The invisible parts just haven't been built yet, and the checks below tell you how many of them are missing.

The 30-minute self-test: 8 checks

Run these only on an app you own or are authorised to test. Most checks just need your browser and your admin dashboards. Score each one Pass (0), Warn (1) or Fail (2).

1. Secret keys in the browser bundle (4 min)

Anything your app sends to the browser can be read by anyone who visits it.

Open your live app in Chrome. Press F12 to open DevTools, then go to the Sources tab.
Press Ctrl+Shift+F (Cmd+Option+F on Mac) to search across all files.
Search for sk_live, sk_test, rk_live, sb_secret_, service_role and secret.
Open your Supabase project's API keys page. Copy the first 20 or so characters of the secret / service_role key and search for those too. Legacy Supabase keys are encoded, so the word "service_role" may not appear in plain text.

Pass: you only find publishable keys (pk_live_, sb_publishable_, the anon key). Stripe and Supabase both say these are safe to expose (Stripe, Supabase).
Fail: any secret, restricted or service key shows up. Rotate it today, before anything else.

2. Row Level Security (5 min)

Supabase's own docs are blunt: a table without RLS "is readable and writable by any role with a grant on it" (Supabase RLS).

In the Supabase dashboard, open Advisors → Security Advisor. Look for errors like RLS Disabled in Public or Sensitive Columns Exposed (Supabase Advisors).
Run the two-account test. Sign up as User A and create a record (an invoice, a project, a message) and copy its URL. Then sign in as User B in a private window and open that URL.

Pass: the advisor is clean and User B sees nothing.
Warn: the advisor shows warnings, but the two-account test holds.
Fail: any RLS error, or User B can see A's data. One catch: Lovable's built-in scanner only checks whether a policy exists, not whether it actually blocks access (Superblocks). The two-account test is what proves it works.

3. Auth and session handling (4 min)

Log out, press Back, then reload a private page. Do you still see data?
Signed in as a normal user, type /admin (or whatever your admin route is) straight into the address bar.
Run a password reset from start to finish. Does the email arrive, and does the link expire after you've used it?

Pass: all three behave. Warn: the reset flow is flaky. Fail: a normal user can reach admin pages, or a logged-out session still shows data.

4. Payment webhooks (5 min)

A webhook is the message Stripe sends to your app's server when a payment succeeds or a subscription changes. Many prototypes skip it and unlock paid features when the browser lands on the "success" page, which breaks the moment someone closes the tab.

In Stripe, open Workbench → Webhooks. Is an endpoint registered at all? Open Event deliveries and look for anything marked Failed or Pending (Stripe webhooks).
In a sandbox, start a checkout, pay with a test card and close the tab before the redirect finishes. Does the account still upgrade?
Cancel that test subscription from the Stripe dashboard. Does the app take away access?

Pass: an endpoint exists, deliveries succeed and both tests behave. Fail: there's no endpoint, deliveries are failing, or access doesn't follow what Stripe says.

5. Data model sanity (5 min)

This is the check that decides fix versus rebuild. Open Supabase's Table Editor and look for:

Tables named after screens (dashboard_data, page_two) instead of things in your business (customers, orders).
The same fact stored in several places, like a customer's email in four tables.
Lists crammed into one text or JSON column.
User-owned tables with no column saying who owns each row.
Something your business does now that the schema can't represent, such as teams, multiple locations or more than one price per product.

Pass: none of these. Warn: one or two, and they're contained. Fail: the last bullet is true, or most of the others are.

6. Error monitoring (2 min)

Who finds out first when something breaks, you or your users? In DevTools, search the Network tab for sentry, logrocket or bugsnag, then check whether you've ever actually received an alert.

Pass: errors reach you automatically. Fail: your users are your monitoring.

7. Page load with realistic data (3 min)

Fill a test account with the amount of data your heaviest customer has. In DevTools, set Network throttling to Slow 4G and load your busiest page.

Pass: the main content appears within about 2.5 seconds. Google's web.dev counts Largest Contentful Paint at 2.5s or less as "good" and over 4s as "poor" (web.dev). Warn: 2.5 to 4 seconds. Fail: over 4 seconds, or the Network tab shows the page downloading an entire table at once.

8. Code in version control you own (2 min)

Is your code in a GitHub repository under your account or organisation? Lovable can create a private repo on your GitHub with two-way sync (Lovable docs). Bolt and Cursor projects should be in a repo too.

Pass: you own the repo and can see a history of changes. Warn: a repo exists but sits in a freelancer's account. Fail: the code only lives inside the builder or on one person's laptop.

Scoring: ship, fix, refactor or rebuild

Add up your points (maximum 16). These thresholds are our rule of thumb from how these problems usually group together. They aren't an industry standard.

Score	Also true	Verdict	What it means
0–2	No Fail on checks 1–4	Ship	Keep building. Add monitoring if you don't have it.
3–7	—	Fix	Targeted repairs. Security fails (checks 1–2) go first, this week.
8–16	Check 5 is Pass or Warn	Refactor	Keep the product and the data, but restructure the code in stages.
8–16	Check 5 is Fail	Rebuild	The foundation can't hold your business. Plan a staged rebuild.

A low score with a Fail on check 1 or 2 still means act today. Rotate the key or turn on RLS, then carry on.

When rebuild is actually right (and when it's a sales pitch)

Most of the top guides agree, and so do we: the data model is the real test. Axonbuild argues that rebuilding is only justified when your data model "cannot express what the business now does" (Axonbuild). Appmatic puts it as refactor if the data model is sound, rebuild if the architecture can't support the roadmap (Appmatic).

Rebuild is right when:

Check 5 fails and your next three features all need the schema changed.
Every small change breaks something unrelated, and that's been true for months.
You can't get the code out of the platform at all.

It's probably a sales pitch when:

Someone quotes a rebuild without reading your code or schema.
The reasons are about taste ("the code is messy", "we'd use a different framework"). Messy code that works is a refactor job.
Exposed keys or missing RLS are given as the reason. Those are fixes, usually small ones.

What to hand a developer

To hand off a Lovable app to a developer (or a Bolt or Cursor one) without paying for discovery twice, send:

Your self-test scores, with screenshots of anything that failed.
Admin or collaborator access to the GitHub repo, Supabase, Stripe, hosting and your domain registrar. Use invites, never shared passwords.
A list of what's breaking, from user reports, with dates.
The next three features you need, so they can judge whether the data model will cope.
Your user and data numbers: active users, the biggest account, the largest tables.

If you'd rather not assemble this yourself, Banxal's maintenance and growth work starts with the same handover review before anything else is touched.

Fix or rebuild a vibe-coded app: what each option involves

Fixing, refactoring and rebuilding a vibe-coded app differ in what changes, what you keep, and what it costs. Cost ranges below are other agencies' published figures, not ours, and your app may differ.

	Fix	Refactor	Rebuild
What changes	Specific broken items	Code structure, tests, deployment	Code and usually the data model
What you keep	Everything	Product, data, most UI	Product knowledge, users, migrated data
Risk	Low	Medium	High: data migration and two systems running side by side
Published ranges	Axonbuild: 6–12 hour repairs at $240–$960 each	Appmatic: 4–10 weeks, $15,000–$40,000	Appmatic: 8+ weeks, $40,000+

Axonbuild's advice on the cost to fix a vibe-coded app is simple arithmetic: count your blocking problems, multiply by the cost per repair, and compare that with a rebuild quote (Axonbuild). Appmatic lists a separate code audit at 1–2 weeks from $2,500 (Appmatic).

FAQ

Is my Lovable app production ready if the Security Advisor is clean?
Not on that alone. The advisor finds missing RLS, but it can't tell you whether your policies match your business rules. Run the two-account test, and check payments and auth as well.

Can I run an AI-built app security check myself?
You can do the first pass. Checks 1–4 above catch the issues behind the best-known incidents. A developer still needs to review webhook signature checks and server-side logic, because that can't be seen from the browser.

How long does it take to fix a vibe-coded app?
Isolated issues such as a leaked key or a missing policy often take hours. The published ranges above put a fuller hardening at weeks. Your score is a better guide than any average.

Next step

If your score says fix or refactor, the next step is a code review and handover conversation. Bring your self-test results. Banxal builds and hardens web apps and SaaS products, and can look after them afterwards through ongoing maintenance. We'll tell you plainly if a rebuild isn't needed. Talk to us about your app.

Originally published on banxal.com.