The shift sneaks up on most founders I speak to. The app you built in an afternoon inside Lovable or Bolt, the one you half expected to throw away, is quietly becoming the thing itself. Someone paid for it, someone emailed you when it went down, and somewhere in there it stopped being an experiment and became a product without any announcement.
I want to be clear about something first. A builder like Lovable, Bolt, Replit or Cursor is the right place to start, and often the right place to stay for a good while. Getting an idea in front of people fast and changing it every day is exactly what these tools are built for, and leaving too early costs you the speed that made them worth using. You shouldn’t move because a blog post told you serious founders self-host. Move when your app tells you it has outgrown the tool.
Here are the signs it’s telling you. None of them mean you did anything wrong. They mean the thing worked.
1. People now rely on it
The clearest sign is the quietest one. Someone is paying you, or using your app to do real work they can’t easily redo. A small business runs its bookings through it. A team keeps its notes in it. The day that becomes true, downtime and lost data stop being hypothetical and become a cost you carry.
While your app was a prototype, an outage was an inconvenience you fixed when you noticed. Once people depend on it, an outage is a broken promise, and a lost database is somebody else’s work gone. This has little to do with how many users you have. One paying customer who trusts you is enough to move the stakes.
2. You are fighting the tool
Every builder has a shape of thing it does well and an edge where it starts to struggle. For a while you work happily inside that shape. Then you want something outside it: a job that runs every night whether anyone is looking or not, an integration with a service the builder doesn’t know about, a specific rule in your database, a piece of logic the AI keeps getting subtly wrong.
You will know this one by the feeling. You’re spending more time coaxing the tool than the change would take a developer to build directly. The prompts get longer and more defensive. You add a workaround on top of a workaround. That friction is information. It means your product now needs a kind of control the builder wasn’t designed to hand you.
3. The bill is now about credits, not product
Early on, you pay a builder to build, and that’s a fair trade: the credits buy you speed. But watch what the bill is for once your app stops changing much. If you’re paying for build credits or a higher tier mainly to keep a stable, finished product online, the arrangement has quietly gone strange.
A live product that has settled down needs hosting, which is cheap and boring, and occasional changes, which is what a builder is for. Paying builder prices to host something you have stopped building is like renting a fully staffed workshop to store a finished chair. You have moved from building to running, and you’re still paying for the first. I wrote about how these bills creep up in how AI-built apps run up surprise bills.
4. You want to hire a developer or bring in a co-founder
At some point the work outgrows you, and you decide to bring in someone technical. This is a happy milestone, and also where a lot of builders quietly become a problem.
Professional developers work in a particular way. They keep code in version control so they can see every change and undo any of it. They run the app on their own machine. They write tests so a fix in one place doesn’t break something in another. Many builders make some of that awkward, because they were designed for a solo founder prompting in a browser. If your new hire spends their first week wrestling the tool instead of improving the product, that’s the sign. I go into what a smooth handover looks like in could another developer take over your app?
5. Security, privacy or compliance has become your problem
Real users bring real data: names, emails, messages, sometimes payment details. The moment you hold that, you have obligations, both legal ones and the plain human duty not to leak someone’s information. Meeting them takes controls that reach into how the app stores data and how secrets like API keys are kept.
The trouble is that a builder gives you the parts it chooses to expose, and the controls you need here often sit below that line. You want to check exactly how a piece of data is stored, or make sure one user can never load another’s records, and you can’t reach the level where that lives. When protecting your users needs reach the builder doesn’t give you, the app has outgrown it. Two pieces worth reading are can your users see each other’s data? and what GDPR asks of your AI-built app.
6. You cannot get at your own code or data easily
This is the one I would ask you to take most seriously, because it’s about ownership. Can you get a full copy of your app’s code onto your own computer today, and a full export of your data, without it being a fight? If yes, you have options and can move whenever you choose. If no, you’re more locked in than you realised.
If you can’t take a full copy of the app with you, you don’t really own it, whatever the arrangement feels like day to day. That’s a fine trade while everything is disposable. It’s a worrying position once the app matters, because your ability to leave, hire, back up and recover all depend on holding your own code and data in your hands. The good news is this is usually the first thing you can fix, and fixing it doesn’t mean leaving the builder at all.
When to stay put
Now the other side, because moving too early is a real mistake and I would rather you not make it.
If you’re still working out whether people want what you’ve built, stay. Changing the product every few days is the whole game at that stage, and the builder does that faster than anything you could switch to. If you have few users or none yet, the risks in this piece are mostly hypothetical, and hypothetical risk isn’t worth trading away real speed. And if the builder still does everything you need, with no daily friction and no wall you keep hitting, there’s nothing to fix.
None of the signs above is a countdown. When two or three of them are true at once, that’s usually the point where moving starts to save you more than it costs. Before that, moving is work you didn’t need to do yet.
Where to start
If some of this landed and you think your app is getting close, don’t panic-migrate everything in a weekend. Take the one step that keeps every option open and commits you to nothing: get your code into version control that you own.
The practical way to do that’s GitHub sync, and most builders support it directly. It gives you a full, live copy of your code in an account that belongs to you, updated as you keep working in the builder. You lose nothing and gain the ability to leave, hire or back up whenever you want. I’ve written it up step by step in how to enable GitHub sync on your vibe-coded app. When you’re ready for the full move onto hosting you control, how to move your vibe-coded app onto hosting you own walks through that, and the launch checklist lays out the whole job of getting ready for real users.
If you’re not sure whether it’s time, or you can see that it’s and would rather not move alone, that’s what I do. I can look at your real app, tell you plainly where it sits, and either hand you a prioritised plan or do the move for you. Either way you make the call on your own terms, with your eyes open, rather than in a scramble the week something breaks.
