Get your code out of the builder

Should you actually move?

A migration is a week or more of work that produces no new features and nothing your users will notice. It's the right call for some reasons and a wasted month for others, and the difference is worth being honest about before you commit.

Good reasons to move

• You need something the platform can't do — a specific region, dedicated database resources, background workers, a compliance requirement, a queue

• The bill grows with users and the economics stop working at your next tier

• A customer or investor has asked where the code lives, who can access it, and what happens if the vendor changes terms

• You're hiring engineers who need a normal workflow — branches, code review, CI, local environments

• You're being acquired and the buyer wants the asset, not a platform account

Bad reasons to move

• The app is broken and you assume a new home will fix it. It won't. The problems travel with the code, and you'll arrive somewhere unfamiliar still holding them.

• You read that the platform is limiting. It might be, for someone else's app, at a scale you haven't reached.

• The generated code looks untidy. Untidy code runs perfectly well. Refactoring is a separate and much cheaper decision.

• You want to feel more in control. Real feeling, and not worth a month unless something concrete is actually blocked.

We'll tell you which of these applies to you, in the audit, before you commit to anything. A migration recommended without that reasoning is a migration someone wants to sell you.

If the answer is yes — here's what you're actually taking on.

Exporting the code is about a tenth of the job

That's the part people focus on, because it's the part with a button.

The work is in everything the platform was quietly doing for you: provisioning a database, injecting environment variables, handling auth redirects, serving files, running scheduled tasks, terminating SSL. None of that is in your repository, and all of it has to exist somewhere new.

And where does it go?

Where you can move to

There isn't one right answer. The right one depends on what forced the move in the first place.

The hybrid option is under-considered and worth asking about. If Supabase is working fine and the problem is the hosting layer, moving only the hosting layer halves the work and most of the risk.

If you have live users, sequence matters more than speed.

Migration without downtime

Step six is where migrations leak money. Nobody remembers to cancel the old subscription, and a fair number of companies are paying two hosting bills months after a successful move.

Some of this you can establish yourself.

Three things worth checking first

These won't move anything. They'll tell you how big the job actually is, which is the thing you need before deciding.

Connect your project to GitHub, if it isn't already Most builders support this directly. Do it regardless of whether you migrate — it means your code exists somewhere other than inside one vendor's account, which is half the reason people want to move in the first place.

Count your environment variables Open the list. Every one of them has to be re-created by hand somewhere new, and each is a silent failure if missed. The length of that list is a reasonable proxy for how fiddly the migration will be.

Find your scheduled jobs and functions Anything running on a schedule, or any serverless function the platform provides. These are the pieces with no direct equivalent elsewhere, and they're the ones that turn a three-day migration into a two-week one.

If that last list is empty and your variable count is small, this is a genuinely small job and you may not need us.

When it's worth getting help

You have live users and real data. The cutover is the risky part, and doing it once properly beats doing it twice.

Payments are involved. Webhook endpoints, live keys and subscription state all have to move without a gap, and a gap here has a cost attached.

You can't name what's coupled to the platform. That's what the audit establishes, and guessing at it is how migrations overrun.

There's a deadline attached — a customer, a funding round, an acquisition. Sequence matters more under a deadline, not less.

What you get

• The application running on infrastructure you own, with the code in your repository

• Every environment variable, secret and credential re-provisioned and inventoried

• A deployment pipeline your team can run — branches, staging, production

• Data migrated with integrity verified rather than assumed

• Platform-specific pieces rebuilt properly, not approximated

• Documentation of what changed and how to deploy from now on

• A rollback plan you hopefully never needed

What we won't do

• Recommend a move you don't need. It's the easiest large engagement to sell and the easiest to regret.

• Quietly turn a migration into a rebuild. If we find things worth fixing, we tell you and you decide.

• Cut over before everything has been verified on the new environment.

One thing about cost, since it's usually the reason.

The bill isn't always the real number

If you're moving because the platform is getting expensive, the comparison worth making is total cost, not the invoice.

Managed hosting has a bill. Self-hosting has a bill plus the hours someone spends maintaining it. A platform that handles your database, auth, storage and SSL is replacing four services you'd otherwise pay for and configure separately — so a smaller hosting bill doesn't always mean a smaller total.

At real scale the migration usually does pay for itself. Below that, the honest answer is often that you're paying for convenience and it's still worth it.

We'll model it in the audit rather than assuming either way.

Questions

Can I just export the code and self-host it? You can export it. Whether it runs depends on how much the platform was doing for you — usually auth, storage, functions and environment configuration. The export is step one of about eight.

Will my app break during the migration? Not if it's sequenced properly. The new environment runs in parallel and is fully verified before anything switches. The only unavoidable interruption is a short data sync at a time you choose.

Will users have to log in again? Yes, once. Sessions don't transfer between auth systems. Accounts, data and history all do.

How long does it take? A simple app with no live users, a few days. A live app with payments, integrations and real data, two to four weeks including verification and a safe cutover.

Can I keep using the builder afterwards? Not on the migrated app — that's the trade. If rapid iteration matters more to you right now than control, that's a legitimate reason to stay and we'll say so.

What about Supabase — does that move too? Only if it needs to. Supabase runs independently of the builder, so most migrations leave it exactly where it is.

Can you fix things while you're in there? Yes, and it's often the efficient moment. It's scoped separately so the migration doesn't quietly become a rebuild.

What if the audit says don't move? Then that's the answer and you've lost nothing. It happens often enough that we put the reasons at the top of this page.

Will you sign an NDA? Yes, mutual, before you send anything. One senior engineer reads your code, never used for training, access removed after delivery.

Send us the repository

You'll get what's coupled to the platform, what transfers cleanly, what has to be rebuilt, where to move it — and an honest view on whether moving is the right call at all.

Read access is enough. Mutual NDA first if you'd prefer.

Request the audit

Also relevant

Codebase takeover · Production readiness · Supabase · Security audit · Works in preview, breaks after deploy