MeetYourMind.

Overview

MeetYourMind is a personality testing SaaS (20 traits, 2×10¹⁸ personality combinations). The entire infrastructure was locked into Lovable Cloud, a managed wrapper over Supabase. The founder wanted out: own GitHub repo, own Supabase project, own Cloudflare deployment, own keys, and the ability to continue building with normal developer tools or AI coding agents instead of one proprietary surface.

Problem

Lovable did not offer a clean full-database export. The CSV format was non-standard: semicolon delimiters, JSON arrays where PostgreSQL arrays were expected, and a couple of generated columns that Supabase quietly rejected on import. Auth users had bcrypt password hashes that needed to survive the move. And the founder had to come out the other side with a stack he could hand to any developer or AI tool, not just to me.

Constraints

• 72 live users with bcrypt hashes that had to survive the move. No forced password resets.
• Zero data loss across 9,778 rows in 27 tables. Verified pre and post.
• Custom domain had to come up cleanly on Cloudflare Pages with SPA routing.
• Three weeks of focused execution, not three months.
• The founder owns every production account at the end. Stripe, Cloudflare, Supabase, Resend, domain, AI keys. Not me.

Decisions

• Migrate auth users with their bcrypt hashes intact, not by inviting them to reset. Keeps the migration invisible to the user base and preserves trust.
• Build a Python data-cleaning script for Lovable’s non-standard CSV (semicolon delimiter, JSON-to-array conversion) instead of hand-massaging tables.
• Run the import inside a single transaction with FK-aware load order, dynamic TRUNCATE, and session_replication_role = replica so referential integrity stays strict.
• Solve the generated-column bugs with a stage-then-insert pattern. The Supabase docs do not mention this. It took eight iterations to land a working shape.
• Add a CI/CD guard-rail that rejects any deploy still pointing at Lovable. The migration is not done if the next developer can accidentally undo it.

What I built

• 46 database schema migrations applied to a fresh Supabase project, zero errors
• Migration of 9,778 rows across 27 tables with verified pre and post row counts per table
• Auth migration of 72 users + 72 auth identities with bcrypt password hashes intact
• Python data-cleaning pipeline for Lovable’s CSV format
• Transactional SQL import with FK-aware load order and replica-role bypass
• Stage-then-insert pattern for two undocumented Supabase generated-column bugs
• GitHub Actions to Cloudflare Pages CI/CD pipeline, with a guard-rail that refuses any deploy still pointing at Lovable
• Full dependency audit: 17 DB rows with hardcoded Lovable URLs, 27 storage files, 3 edge functions, 6 code files, 10 secrets to transfer
• 858-line migration playbook as a reusable asset for the founder’s next developer

Result

• 9,778 rows migrated, zero data loss
• 72 users with passwords intact, zero forced resets
• 46 schema migrations applied, zero errors
• Full vendor lock-in removed
• Custom domain live, CI/CD active, founder owns every production account

Reflection

The hardest parts were not the SQL. They were the parts the docs did not warn you about: a CSV export pretending to be standard, two Supabase bugs with no public mention, and the discipline of treating a migration as “done” only when the next developer cannot accidentally undo it. The 858-line playbook exists so the founder never has to call me to find out where something lives.