Lovable is the fastest way to build a frontend. But 'build a frontend' and 'ship to production' are different things. Production means a real backend, real auth, real data, and a deployment pipeline that doesn't involve copying files. I've shipped six Lovable projects to production in the last three months. Here's the complete playbook.
Step 1: Connect Your Repos
Create an AppHandoff project and connect two repos: your Lovable frontend repo (the one Lovable auto-commits to) and your production backend repo. AppHandoff needs read access to both via the GitHub App. If they're in different GitHub orgs, you'll authorize both orgs during installation.
This takes about 90 seconds. No config files, no YAML, no webhooks. The connection is bidirectional — AppHandoff reads both repos and extracts contracts from each.
# What AppHandoff extracts on connect:
Frontend (Lovable repo):
→ fetch() / axios calls → endpoint paths + HTTP methods
→ TypeScript interfaces → expected response shapes
→ Route definitions → page structure
→ Auth hooks → authentication expectations
Backend repo:
→ OpenAPI spec → actual endpoint definitions
→ Route handlers → implemented endpoints
→ DB schema → data model
→ Auth middleware → security requirementsStep 2: Run the First Scan
The first scan runs automatically when you connect repos. It takes 10-30 seconds depending on repo size. The result is a mismatch report — every place where the frontend expects something the backend doesn't provide, and vice versa.
Expect mismatches on your first scan. A lot of them. A typical Lovable prototype with 8-10 pages generates 15-25 mismatches against a fresh backend. That's normal — it's the gap between 'prototype' and 'production' made visible. Each mismatch is a concrete ticket with file paths, line numbers, expected vs. actual data shapes, and a severity rating.
Step 3: Read the Mismatch Report
Don't panic at the mismatch count. Triage by severity. Critical mismatches are missing endpoints the frontend actively calls — those need to be built. High mismatches are shape disagreements — the endpoint exists but returns the wrong structure. Medium mismatches are usually auth gaps or pagination differences. Low mismatches are cosmetic — enum naming differences, optional fields.
# Example mismatch report (first scan):
CRITICAL (4):
POST /api/projects → endpoint missing in backend
GET /api/projects/:id/team → endpoint missing in backend
POST /api/auth/signup → endpoint missing in backend
GET /api/billing/plans → endpoint missing in backend
HIGH (6):
GET /api/projects/:id → FE expects { project: { members: [] } }
BE returns { id, name, created_at }
GET /api/users/me → FE expects { avatar_url, plan }
BE returns { id, email }
... (4 more)
MEDIUM (3): auth header mismatches
LOW (2): enum naming differencesStep 4: Let Bots Plan, Humans Decide
Each mismatch ticket gets an AI-generated implementation plan. The plan describes what needs to change, in which files, and why. Your job is to review the plan — not the code. Does the approach make sense? Is an alias better than a rename? Should the frontend adapt to the backend or vice versa?
Plan review is the highest-leverage step in the entire pipeline. A five-minute plan review prevents hours of wasted code review later. We've seen agents propose plans that would rename database tables when an API alias would do. Catching that at the plan stage saves everyone's time.
Step 5: Review PRs and Merge
Once you approve a plan, the agent writes the code and opens a PR. The PR includes a diff summary, a link to the originating mismatch ticket, and CI check results. Review it like any other PR — check the logic, verify the tests, confirm the approach matches the approved plan.
Most mismatch fixes are small — 10-50 lines. Adding a missing endpoint, adjusting a response shape, adding an auth header. The PRs review quickly because the scope is tight. The shared Kanban board (/shared-kanban-humans-bots) tracks every ticket through the pipeline so nothing falls through the cracks.
Step 6: Deploy and Verify
After merging, deploy to your staging environment. AppHandoff triggers a post-deploy scan to verify the mismatches are actually resolved. If a fix didn't fully resolve the mismatch — maybe the response shape is close but not exact — a new ticket appears. The closed-loop pipeline (/closed-loop) ensures nothing gets marked 'done' until it actually works.
# Full pipeline timeline (real project, 23 mismatches):
Day 0: Connect repos, first scan → 23 mismatches
Day 0: Triage: 4 critical, 8 high, 7 medium, 4 low
Day 1: Bot plans approved for 18 tickets (5 need human decision)
Day 1: Bot opens 12 PRs → 10 merged same day
Day 2: Remaining 6 bot PRs merged, 5 human tickets in progress
Day 3: All 23 mismatches resolved. Clean scan.
Day 3: Deploy to staging → post-deploy scan → 0 mismatches
Day 4: Production deploy. Done.
Total human time: ~6 hours (plan review + PR review + 5 manual fixes)
Total elapsed time: 4 daysOngoing: Continuous Sync
Here's where it gets good. After the initial push to production, every subsequent change to the Lovable repo triggers a fresh scan. Designer iterates the prototype? Scan runs. New page added? Scan runs. API call changed? Scan runs. Mismatches are caught in minutes, not weeks.
The prototype stays connected to production permanently. No re-porting, no manual audits, no 'wait, did the API change?' The MCP server (/mcp-server) powers the continuous scanning, and the pricing page (/pricing) breaks down the plans based on scan volume and team size.
Common Gotchas
Three things trip up every first-time user. First: mock data in Lovable. If your prototype uses hardcoded arrays instead of real API calls, the scanner won't detect those as contract expectations. Switch to real fetch calls early. Second: missing OpenAPI spec. The scanner works without one, but accuracy improves dramatically with a spec. Third: auth middleware. If your backend uses custom auth that isn't in the standard Bearer token pattern, configure the auth paths in project settings to avoid false-positive mismatches.