The lock-in in AI app builders isn't the hosting. It's the build config.

Two months ago my production backend went offline. Not a bug, not traffic — my credit balance hit zero, and the managed backend shut down with it. No users were affected, since I don't have paying customers yet, but the product was simply gone, for a reason that had nothing to do with my code.

That week I moved the database to my own Supabase. Harder than expected, for a boring reason: the dump was a custom-format file with zstd blocks and pg_restore refused it. I ended up reading the TOC with pgdumplib and pulling the data out by hand. 16 tables, 362 rows, 6 accounts with their original password hashes. I compared md5 on both sides before switching over. It worked, and the app has run on my own database ever since.

Last month I looked into moving the hosting too. That's where it got interesting.

I expected "connect GitHub, deploy elsewhere." But the build config isn't really mine. It imports a proprietary package that already bundles the framework, Tailwind, path aliases, env injection and the server adapter — and the file itself warns that adding those plugins manually breaks the app through duplication. Leaving isn't a deploy step. It's rebuilding the build.

That reframed the whole thing for me. I always assumed the lock-in in these tools was the hosting — the part you walk away from in an afternoon. It isn't. The database moved in two days. The build config is what actually holds you.

I'm not saying avoid them. I shipped a real product fast and probably wouldn't have otherwise. But if you're starting now: own your database from day one, and read your build config before you assume you can leave whenever you want.

Has anyone here actually finished a migration off one of these? Curious how long it really took.