Skip to main content
AC
Delivery & Handoff4.2 KBMIT licensed

techtide-lovable-production-handoff

Original, written for TechTide client work

Convert a Lovable prototype into a repo-owned production candidate by inventorying, replacing mocks, and adding tests and deployment gates. Use when a prototype needs to leave Lovable for a real repo, CI, and production. Not for starting new Replit projects (use techtide-replit-fullstack-bootstrap), hardening v0 UI prompts (use techtide-v0-ui-prompt-hardener), or packaging skills for Lovable (use lovable-native-packaging-bridge).

  • techtide
  • lovable
  • production
  • handoff

SKILL.md

Lovable Production Handoff

A prototype earns production status by surviving extraction, not by looking finished in the preview. Inventory everything, mark every mock, and gate promotion on documented operational posture.

Workflow

  1. Inventory. List routes, components, data calls, auth behavior, environment variables, and dependencies. This list is the handoff contract, anything not on it does not exist.
  2. Mark before replacing. Flag every mock, localStorage fallback, and placeholder integration in the code before changing any of them. Replacing unmarked mocks is how one survives to production.
  3. Move to a real repo. Package manager, lint, test, build, and deployment scripts. The app must build and run outside Lovable from a clean clone.
  4. Test the critical paths. Smoke tests around user-critical flows, plus a visual check at the first viewport (375px).
  5. Gate promotion. Block production until secrets handling, auth, observability, and rollback posture are documented. Read references/adapter-map.md when the handoff also needs companion outputs for Cursor, Kiro, v0, or Replit.

Output contract

Return a concise brief with:

  • Handoff inventory.
  • Mock replacement plan (each mock: what replaces it, and when).
  • Test plan.
  • Production gate report.
  • Verification performed and still required.
  • Security and privacy notes.

Guardrails

  • Extract reusable methods, never private local content.
  • Never request or expose credentials, tokens, DSNs, service-role keys, customer data, or business exports. Record variable names only, values live in the secret store.
  • Placeholders for people, accounts, projects, URLs, and datasets unless the user supplies public-safe values.
  • Explicit human approval before production mutation, external messaging, public deployment, billing changes, or destructive filesystem actions.

Good vs bad

Good mock replacement plan entry: "useOrders returns fixture JSON (src/hooks/useOrders.ts:12). Replace with server fetch against /api/orders, auth required, before beta. Until then the route shows a 'demo data' banner."

Bad: "Swap out the fake data before launch." No location, no replacement, no deadline, no interim safeguard. That mock ships.

Verification

Do this: clone the extracted repo fresh, run install, lint, test, and build, then start the app and exercise each smoke-tested flow. Expect all commands to exit zero and every flow to work without Lovable-only assumptions (no missing env, no localStorage-seeded state). If anything fails, the handoff is incomplete: fix the repo, not the demo.

Completion checklist

  • [ ] Inventory covers routes, components, data calls, auth, env vars, dependencies
  • [ ] Every mock and fallback marked before replacement started
  • [ ] Clean-clone build, lint, and tests pass
  • [ ] Smoke tests cover the user-critical flows
  • [ ] Production gate report documents secrets, auth, observability, rollback
  • [ ] Human approval obtained for any production-affecting action

Any box unchecked: not done. Fix or say so.

Footguns

  • Trusting the Lovable preview as proof: the preview injects environment and state a clean repo does not have. Only the fresh-clone run counts.
  • Replacing mocks by search-and-delete: fallback branches (|| demoData) survive greps for the mock name. Mark first, then replace against the marked list.
  • Copying env values into the repo "temporarily": the temporary commit is permanent history. Names in code, values in the secret store, from the first commit.
  • Promoting with observability "planned": an app you cannot see failing is not production-ready, it is production-invisible.

Reference files

More in Delivery & Handoff

All skills