Lovable can get you to a working MVP in weeks. The engineering hand-off is where the hidden cost shows up.
A clean Lovable hand-off is not "here is the GitHub repo." It is a set of artifacts that let a new team boot the app, deploy it, observe it, explain it, and change it without the original prompt history open in another tab. Skip those artifacts and you do not save time; you move the 4-8 weeks we would normally budget for first understanding onto the receiving engineer's invoice.
Imagine you're the CTO inheriting a Lovable app from a founder who moved fast and actually found demand. The repo opens cleanly. The code is consistent. Three weeks later, a customer reports that Romanian users should not see a discount banner, and nobody can tell whether that rule lives in React, an Edge Function, a database policy, or a prompt the founder wrote at midnight.
That is not a Lovable problem in the narrow sense. It is a code hand-off problem made sharper by AI-generated code and vibe coding: the code can work while the product knowledge lives somewhere else.
The artifact list costs less than the first week of archaeology
A medium-to-large legacy codebase can take 6-12 months to understand properly. For a 30k-line Lovable app with a sane hand-off package, appssemble would usually budget 4-8 weeks for first understanding. Without the package, the receiving team spends the first month rebuilding the missing context instead of shipping product work.
The artifact list is boring because it needs to be boring. You need the GitHub repo with history, owner access transferred, branch protections recreated, CI secrets moved, and a README.md tested on a clean machine. You need the Supabase schema, migrations, RLS policies, Edge Functions, storage buckets, backups, and restore procedure.
You also need everything around the code: DNS, hosting, billing accounts, OAuth clients, Stripe, Resend, Twilio, Sentry, PostHog, OpenAI or Anthropic keys, and a real secrets vault. Lovable's own export path does not include API keys and secrets, so "we exported the code" is not the same as "we can run production." Lovable's own hosting guidance draws the same boundary: once you stop using the platform, you own CI/CD, production infrastructure, databases, storage, auth, OAuth flows, secrets, AI provider accounts, monitoring, and compliance.
The final layer is decision context. An ADR log, even a retroactive one, tells the next engineer why Supabase Auth was chosen over Clerk, why the checkout flow stores state where it does, and why a specific table has a strange policy. A 30-minute walkthrough of the founder using the product is often worth more than a week of source reading.
Lovable's consistency hides the decisions
The first failure is knowledge. Lovable can produce code that looks more consistent than a human team would write, which sounds good until you need to know which parts are deliberate.
Human code often carries scars: a weird filename, a comment, a failing test, a half-finished refactor, an ugly helper that clearly handles a painful customer case. AI-generated code can flatten all of that into grammatically neat functions and calm naming. The receiving engineer cannot tell which decisions were load-bearing and which were accepted because the preview worked.
The fix is not a 40-page wiki. It is three small artifacts. 1. An ADR log: record the 10-15 choices that would hurt to reverse. 2. A frequency map: identify the top 5 user journeys and the files that change most often. 3. A walkthrough: record the founder using the product while explaining intent, shortcuts, customer exceptions, and known bugs.
This is where appssemble treats hand-off as engineering, not admin. Our engineering team wants the code, but we also want the rationale, the path users take through the product, and the parts nobody trusts yet. The goal is not to admire the repo. The goal is to own it.
Lovable Cloud exports code, not every dependency
The second failure is lock-in at the managed layer. Lovable is relatively portable at the frontend layer: React, Tailwind, shadcn, a package file, and a GitHub repo. The risk lives in auth, Edge Functions, storage, AI gateway calls, region, billing, and secrets.
Some of those parts export. Some do not. Edge Functions may need to be redeployed under a new Supabase project with fresh secrets and CORS settings. Storage buckets need an inventory, a copy plan, and URL handling, because signed URLs or CDN paths can break after cutover.
OAuth is a common trap, but not because Google users automatically become new users. Lovable Cloud supports both Lovable-managed Google OAuth and your own Google Cloud credentials, and its docs say switching between those modes does not affect existing user accounts. The risk is custody and configuration: OAuth client IDs, secrets, consent screens, redirect URIs, and downstream tables that assume a specific provider setup need to be inventoried before cutover.
As of May 2026, the market around this gap is already visible. lovablemigration.com self-reports 50+ apps migrated, $300-$600 fixed-rate pricing, and 3-7 business-day turnaround. NextLovable advertises a $299 audit, $2,500-$4,500 execution, and 3-5 business-day delivery. Treat those pages as vendor claims, not benchmarks, but they show the shape of the work: small enough to plan, concrete enough to price, and painful enough that founders are paying to turn a Lovable export into owned infrastructure.
The honest read is simple. Lovable can be right for launch, and Lovable Cloud can still be the wrong place for your long-term production dependencies. A clean hand-off names each dependency before the receiving team learns about it through a broken login or missing file.
The spec often lives in prompt history
The third failure is implicit logic. In a Lovable build, the spec is not only in code, tickets, or Figma. It often lives in the prompt history: "ignore that earlier checkout flow," "hide this banner for Romanian users," "classify billing tickets differently," "only admins can approve orders above $1,000."
The code contains the result. It may not contain the reason. That distinction matters when the next engineer changes the checkout flow and removes a customer-specific workaround because it looks accidental.
For AI features, the problem gets sharper. A system prompt inside an Edge Function may encode the business rule that classifies support tickets as billing, technical, or spam. Move the function, change the model, or lose the original prompt, and the feature can drift while every test still passes.
There is a large-company version of this pattern. Meta described using 50+ specialized AI agents to read 4,100+ files across an internal data pipeline and produce 59 context files that captured tribal knowledge. A startup does not need that machinery, but the miniature version works: generate docs/features/*.md, copy system prompts into docs/prompts/, and make the founder review the explanations before hand-off.
A receiving team needs a 30/60/90 plan, not a rescue sprint
The first 90 days should not be a blur of refactors. They should prove that the new team can run, change, and defend the system.
By day 30, the incoming engineer should be able to run the app locally, deploy to staging, restore from backup, read the top 5 journeys, and update the README where reality disagrees with docs. They should read recent commits and write the first retroactive ADR before opening a large refactor PR. No refactor sprint earns priority until local boot, deploy, backup restore, and the top journeys are proven.
By day 60, they should have shipped one small user-facing change, stood up missing monitoring, and replaced one managed dependency that creates outsized risk. The AI gateway is often a good candidate because it is contained: issue your own provider keys, route calls through your own proxy, and log failures where your team can see them.
By day 90, the incoming team should own the pager, the rollback path, and the next migration decision. If the outgoing builder is still the only person who knows how auth, storage, billing, or prompts behave, the hand-off did not finish.
Your HANDOFF.md should make the hard parts visible
Put the hand-off in the repo as HANDOFF.md. Keep it short enough that a founder will fill it out, but concrete enough that an engineer can find the missing pieces in one pass.
At minimum, it should cover owners and overlap window, the product in 90 seconds, top 3 user journeys, current usage metric, stack, repo access, branch protection, CI, hosting, secrets vault, env var inventory, database provider, migrations, RLS audit date, backup restore date, Edge Functions, system prompts, domains, DNS, observability, runbooks, ADRs, known unknowns, and the 30/60/90 plan.
That list is not the ceiling. It is the floor. A team that fills it in honestly removes most of the hand-off pain before it becomes senior-engineer archaeology.
We do not treat Lovable as the enemy. It is a fast way to get a product into users' hands. But the moment you hire in-house engineers or ask a finishing team to take over, the real deliverable is not the generated app; it is the evidence that lets someone else own it.
If you're planning a Lovable to in-house migration, run the template before the first engineer starts. If you're already stuck mid-transition, book a call and share your HANDOFF.md. We will tell you which gaps are harmless, which ones push the hand-off into the 4-8 week discovery budget, and what your engineering hand-off should look like before anyone touches production.