Somewhere around the third month of running this site on Lovable, I went looking for the export button. I wanted to see the raw code — not because anything was broken, but because I wanted to know what would happen if Lovable simply wasn't there one morning. Every business I run in Sheridan sits on infrastructure I can walk into and touch: a bank I can call, a bookkeeper I can sit across from, a lease I signed with my own name on it. My own website was the one piece of my operation I didn't actually own. That bothered me more than it should have, and I let it sit for a few weeks before I did anything about it.
What I found, once I went looking, is that the fear is mostly manufactured. A Lovable project is not a black box. It is an ordinary Vite and React app sitting in a Git repository, and the moment that repository lands in your own GitHub account, the platform becomes optional. I moved this site — code, hosting, domain, backend, all of it — off Lovable in an afternoon, and the site never went dark for a single visitor. This is the order I ran it in, and the parts nobody tells you about before you start.
Why this matters more than it looks like it does
If you built something with Lovable, Bolt, v0, or Replit, you already know the appeal. You described what you wanted and a working site appeared in minutes. What most people don't clock until later is what that convenience costs: your code lives in someone else's editor, your images sit on someone else's storage bucket, your domain points at someone else's hosting, and your database — if the platform provisioned one for you — runs on infrastructure you never logged into directly.
None of that is a problem until it is one. A pricing tier changes. A platform gets acquired, or shuts down a feature, or simply raises the number on the invoice. None of these are hypothetical anymore — every AI site builder has had at least one of them happen to somebody's project in the last year. The operator's version of this question isn't "is my current platform trustworthy." It's "what happens to my business if the answer changes." I run everything I operate on the same principle: anything a vendor can take away, price-hike, or lock behind a dashboard eventually will be. A website you can't leave isn't a website. It's a lease you never signed.
The one move that actually matters
Everything below sounds like a lot of steps. It collapses to one: get your code into your own GitHub account. Once that repo exists under your name, with full commit history, everything downstream — hosting, domain, images, the platform's own branding scripts — is just cleanup. You are not extracting anything or reverse-engineering a proprietary system. You are relocating a normal web app and unplugging a few cords that were never load-bearing in the first place.
I want to be specific about what "owned" means at the end of this, because vague language is how people talk themselves out of doing it:
Your source code lives in your GitHub account, with full history, and you can edit it with anything — Claude Code, an IDE, a text editor at 2am.
Your hosting auto-deploys on every push, on a platform you chose and can leave.
Your domain's DNS points at that hosting, not at the builder.
Your images live in your own storage, not hotlinked from a bucket you don't control.
Your database, if you have one, is a project you can log into directly — not a black box the builder manages on your behalf.
Five things. None of them require you to rebuild the site. All of them are true within a few hours of starting.
The order matters — the golden rule is that the site never goes dark
The mistake I see people make when they research this is jumping straight to DNS, because that feels like the "real" step. It's actually the last one, and it's the only one you should treat carefully. Everything before it is fully reversible. Here's the sequence I ran, and the reasoning behind the order:
Phase 0 — Accounts. A GitHub account, and an account on whatever host you're moving to, signed in through GitHub so the two are linked. Ten minutes, and it's the only phase with zero risk of touching your live site.
Phase 1 — Get the code into your GitHub. Inside the builder, there's a GitHub integration — connect it, authorize it, and let the platform push your full source into a new repo under your own account. This is the actual moment of ownership. Confirm the repo exists on github.com with real commit history. Everything after this point is safe, because your source code can no longer disappear with the platform.
Phase 2 — Strip the platform's hooks out of the code. Builder platforms inject a few things into a generated app: a dev-only tagger plugin, a small branding script in the HTML head, sometimes a badge. None of it does anything for your site's actual function — it's telemetry and attribution, and it comes out cleanly. This is also where you find any images being served from the builder's own storage bucket rather than yours, and bring them home. A clean build from scratch, with zero platform dependencies left in the package file, is the proof this phase actually worked.
Phase 3 — Deploy to your own host. Import the GitHub repo into your chosen host. If it's a standard Vite app, the host auto-detects the build command and output directory, and you have a live temporary URL in about a minute. Test everything here, on the temporary URL, before your real domain is anywhere near it.
Phase 4 — Repoint the domain, last. This is the only step that feels irreversible, so it goes last on purpose. Add your domain in the new host's settings, note the DNS records it wants, then go update those records wherever your DNS actually lives — your registrar, or a service like Cloudflare if you use one. Propagation takes minutes to a couple of hours. Your old site keeps serving traffic the entire time the record is still pointed at it, so there's no window where anything breaks. Once the new domain resolves and you've verified it, remove the domain from the builder and let that project sit as a fallback for a week before you retire it.
The DNS record is the only step people think is scary. It's also the only one you can undo with a single edit if something looks wrong.
What actually happened when I ran this, not the theory
The version above is the clean playbook. Here's what the real cutover looked like, because the gap between the two is where people get stuck.
My domain's DNS lived in Cloudflare, and it had accumulated nineteen records over the life of the Lovable project — verification TXT records, a couple of nameserver delegations for the builder's own notification system, the works. Only seven of those were actually the builder's. The rest belonged to email sending and other services I still use. I went record by record rather than trusting my memory of what was "Lovable's," and came out the other side at eleven — the seven builder-only records gone, everything else untouched. That's the kind of cleanup that looks trivial in a runbook and takes real attention when you're staring at a DNS panel deciding whether a given TXT record is safe to delete.
The backend was its own small decision. My database had been provisioned by the platform automatically, which meant it existed but I'd never actually logged into it directly. Migrating it meant standing up my own project on the same underlying service, exporting every table from the old one, verifying row counts matched, and pointing the live site's configuration at the new project — then confirming with an actual network request from the live page that traffic was hitting the new backend, not the old one. I didn't take that on faith. I watched the request happen.
One loose end survived the cutover on purpose: the DNS records handling bounce reports for outbound email still pointed at the builder's inbox, set to monitor-only, which meant no live function depended on it. I left it, rather than touching email authentication configuration I hadn't fully mapped out yet, and came back to it later on my own schedule. Not every loose end needs to close on migration day. The ones that don't affect a live visitor can wait for a day when you're not already holding four other changes in your head.
What to check before you start
Before you open a single settings panel, answer three questions honestly, because they change how much time this actually takes:
Do you already have a GitHub account, and is it one you'll still be using in five years? Don't create a throwaway. Where does your domain's DNS actually live — your registrar, or a separate service? You need to know this before Phase 4, not during it. And does your app use a database the builder provisioned, or is it a static site with no backend at all? A static site skips the entire backend-migration step and the whole project shrinks by half.
None of these questions require technical skill to answer. They require ten minutes of looking, and they're the difference between a migration that takes an afternoon and one that takes a week of confused starts.
What this doesn't fix
I want to be straight about the limits of this, because the pitch for owning your own stack tends to run hotter than the reality warrants. Migrating off Lovable doesn't make your site faster, doesn't improve your SEO on its own, and doesn't change a single thing a visitor sees. If your site was slow or thin on content before the migration, it's slow and thin on content after it too — you've just moved the same site to a different set of keys. The value here is entirely downstream: it shows up the day a platform changes terms on you, not the day you finish the cutover.
It also isn't free in the way "free hosting tier" suggests. Vercel, Netlify, and Cloudflare Pages are free for a personal-brand site's traffic level, but if you outgrow that — real e-commerce volume, heavy media, a database under real load — you'll pay someone eventually. The difference is you'll be choosing who, on terms you can read, instead of discovering the number on a renewal email. And it takes real focused attention, even if it's only an afternoon. If you've never touched a DNS panel or opened a terminal, budget more time for Phase 2 and Phase 4 than the phase list suggests, and don't attempt the domain cutover on a day you can't stay near a computer for the next hour in case something needs a second look.
None of that is a reason to skip it. It's a reason to do it on a slow Tuesday instead of the week before you need the site for something that matters.
What this actually buys you
Nothing about the site changed the day I finished. Same design, same content, same visitors none the wiser. What changed is that the platform I built it on could disappear tomorrow and I wouldn't lose a page. That's not a technical milestone. It's the same principle that runs every business I operate: never build the thing you'd protect on top of infrastructure someone else can take away from you. A website is small enough that most people don't apply that discipline to it. It's also the piece of infrastructure most personal brands actually depend on, which makes it a strange place to leave unowned.
I wrote the full runbook — the exact commands, the specific things to search your codebase for, the paste-ready prompt I used to drive the code cleanup — into a companion guide, because a blog post can tell you the shape of the work and a checklist is what actually gets you through Phase 2 without missing something. If you're on Lovable, Bolt, v0, or Replit right now and this has been sitting on your list for a while, the guide is built to be run in one sitting. And if you want to see the mechanics for yourself first, Lovable's own documentation on deployment and ownership is worth reading before you start — it confirms the same thing this post argues: the lock-in was never structural, just default.
The full version is the Lovable Freedom Pack: every command from Phase 0 to Phase 4, the exact strings to search your own codebase for, the paste-ready prompt that drove the cleanup, and eleven real failures from doing this on a live site — with the fix for each one, not just the warning. Checkout isn't live yet. Leave your email below and I'll send the link the day it is, before it goes anywhere else.
If you'd rather hand this off entirely — this site or someone else's — that's the other conversation to have.
Anything here about money or results describes my own companies. It isn't typical and isn't a promise of yours. See the earnings disclaimer.
DG
Dalton Goodyear
Operator, writer and speaker in Sheridan, Wyoming. Hosting short-term rentals since 2017. Licensed Wyoming real estate broker and founder of Wyo Stays.
