I stopped paying my AI app builder $25 a month to host a finished app. Here is the math.
I am not a developer. I build in Lovable, and a few months ago I finished an app. It worked, I stopped changing it, and I kept paying $25 a month on Pro. Mostly, it turned out, to keep a custom domain and some AI I no longer used.
Here is the part that annoyed me once I saw it clearly: AI builders do not really charge you to build. They charge you to stay. The credit meter only makes sense while you are actively iterating. Once the app is done, you are just renting.
So I moved the finished app off Lovable hosting. Three things I learned, in case you are sitting on the same bill:
-
You do not have to migrate your database to move. You can keep Lovable's managed Supabase and move only the frontend to a cheaper host. That keeps the sync working and it is reversible. Moving Supabase to your own instance is a one way door, so only do it if you want full ownership.
-
The export is just a normal React project. No lock in on the code. The lock in is the confidence gap, not the code.
-
Two things quietly break on a new host: environment variables (every VITE_ one has to be re added) and Row Level Security policies (re test every read and write as a real user). Fix those two and it just runs.
Result: a flat hosting bill, my own domain, and I dropped Pro once I confirmed I was not iterating anymore.
Full disclosure, I ended up close enough to this problem that I co-founded a host for it, so grain of salt on my part. But the lesson stands even if you never touch what I build: separate where you build from where your app lives. They are two different bills, and the tools want you to treat them as one.
Question for the builders here: for those shipping with Lovable, Bolt, or v0, how much are you paying per month right now for apps you have basically stopped changing?
The hosting cost comparison is useful, but I think the time spent migrating matters just as much as the monthly fee.
For someone comfortable with React and deployment, moving away may be straightforward. For a non-technical user, even a small configuration issue could make the original subscription feel worth keeping.
Roughly how long did the migration take you from export to a stable deployment?
Keeping managed Supabase while moving only the frontend is the reversible step most non-developers will miss. I'd turn migration into a two-phase checklist: replicate environment variables and RLS tests, cut DNS, then cancel the builder plan only after a week of clean logs. The confidence gap shrinks when rollback is explicit.
Solid breakdown. Worth adding one thing on the env var point: anything prefixed VITE_ gets bundled into the frontend, so it's public by design. Migrating is a good moment to check none of those are real secrets like API keys or service tokens, because if they are, they've been sitting readable in your client bundle this whole time, new host or old. That's the one that bites people quietly.
This is the one I'd promote out of the comments and into the post, honestly.
The specific way it happens: someone's anon key keeps getting blocked by RLS, they drop the service_role key into a VITE_ variable instead, the app starts working, and they move on. It's not a migration bug at that point — it's a key that's been sitting in the client bundle, readable by anyone who opens devtools, for however many months.
Working rule for anyone reading this who isn't a developer: if a variable name starts with VITE_, treat it as if it's printed on your homepage. If you wouldn't put it there, it doesn't belong in that variable.
Exactly, the service_role into VITE_ move is the classic one. It clears the RLS block and quietly hands everyone your master key. That "treat it like it's printed on your homepage" rule is the version a non-developer actually remembers, stealing that line :). This is honestly the whole reason I'm building a little security scanner for AI-built apps, exposed VITE_ secrets and missing RLS are the top two things I keep finding. Feels like it'd sit naturally next to what you're hosting.
The RLS gotcha is the detail that'll save someone real debugging time. Row level security policies are exactly the kind of thing that works silently until you migrate hosts, and suddenly your own app can't read its own data in production. The bigger point about the $25 being a confidence tax rather than a hosting cost is the one worth sitting with though. A lot of people stay on the expensive all in one plan because leaving feels like admitting the project is finished, when finished is actually the goal.
"Leaving feels like admitting the project is finished, when finished is actually the goal" — that's a sharper version of what I was circling around and didn't land.
That was literally my situation. I kept Pro for months after I stopped touching the app, telling myself it was in case I wanted to tweak something. I never tweaked anything. I was paying for an option I never exercised, and the reason I didn't cancel wasn't money, it was that cancelling made it official.
Which is a weird thing to be avoiding, given that a finished app that just runs is the whole point.
This is the kind of cost breakdown more solo builders need to see. A lot of people focus only on “can I build it?” and forget that hosting, API calls, app store costs, and small subscriptions quietly become the real monthly pressure.
The tricky part is knowing when a paid tool is saving you enough time to justify the cost versus when it becomes dependency tax.
For early products, I think the best rule is:
pay for speed while validating,
cut costs once the product is stable,
and never let the fixed monthly bill grow faster than real user demand.
Curious what surprised you most in the final math — hosting, AI usage, or all the small tools around the app?
Hosting was the smallest line by a lot, and that's exactly what surprised me — because it's the thing the bill is named after.
What I was actually paying for was a custom domain (costs approximately nothing to serve) and AI credits I'd stopped burning. The build capacity was the expensive part, and my usage of it had gone to zero while the price stayed flat.
Which is why I'd tweak your rule slightly. "Never let the fixed bill grow faster than user demand" catches the case where the bill creeps up. My case was worse and quieter: the bill never moved at all, but demand for half of what it covered dropped to zero. A flat bill looks fine on a statement. You have to go looking for it.
The small tools were the least surprising, oddly — those I could at least see myself renewing.
This is a really useful framing: the fixed bill looking harmless until demand drops to zero.
I’m seeing a related version of that with MealRadar, but on the marketing side. The app exists, the feature set exists, but if the demand signal is weak or the positioning is wrong, then even “small” ongoing costs and effort are dangerous because they feel justified without proof.
Your line “go looking for it” is the part I’m taking seriously. I need to look at whether people actually feel this pain strongly enough, not just whether the app works.
Small favor if you’re open to it: could you download MealRadar once and test only the first-use/UI flow? No review needed. You get free AI allowances, and no sign-up is required just to test the UI. One honest note would be more useful than a polite compliment.
App Store: https://apps.apple.com/us/app/mealradar/id6782612975
This is such an underrated point. The “you pay to stay, not to build” framing is exactly what most people miss.
I had a similar realization recently — kept paying for a tool long after I stopped iterating, just because everything was “working” and I didn’t want to risk breaking it. The inertia is real.
Also +1 on the confidence gap. The code is usually fine, but the unknowns (env vars, auth, RLS, etc.) are what keep people locked in.
Curious if more builders are starting to separate build vs host, or if most are still just eating the monthly cost for convenience.
From what I've seen: most people still eat it, and not because they haven't thought about it.
The reason is that "I'm done" never actually arrives as a moment. Nobody sends you a notification saying the project is finished. You just gradually stop opening it, while the charge keeps landing on the same day every month with no relationship to whether you used the thing. There's no trigger to act on.
The people I've seen actually split it did it after one of two things: a bill that surprised them, or a second project — because that's when the math stops being $25 and starts being $25 x N, and N is the number that makes people finally do arithmetic.
"The code is usually fine, the unknowns keep people locked in" is exactly it. Nobody's held hostage by their React. They're held by not knowing which four things break.
'they don't charge you to build, they charge you to stay' is the cleanest way i've seen anyone put it. the credit meter is priced for the iterating phase and then just keeps running after you've stopped.
the RLS point is the one that actually bites people. env vars fail loud (app won't boot, you fix it in five minutes), but a broken row-level policy fails quiet: the app loads fine and serves the wrong user's data or an empty list, and you don't notice until someone reports it. re-testing every read/write as an actual logged-in user, not the service role, is the step everyone skips.
and once a react frontend is genuinely static, the marginal hosting cost on a plain CDN is basically rounding-error money. the $25 was never hosting, it was the confidence gap you named.
"Env vars fail loud, RLS fails quiet" is a better way of saying it than anything in my post. Broken env var and the app won't boot — you find it in five minutes because you can't not find it. Broken policy and the app loads, looks perfect, and returns an empty list.
One thing I'd add on top of your "test as a real user" point, because it's the trap underneath the trap: don't test logged in as yourself if you're the owner or admin. Your own rows come back no matter how broken the policy is, so everything looks green and you ship it.
You need a second throwaway account with data that isn't yours. That's when a broken policy shows itself immediately. You either see somebody else's rows, or you see nothing when you should see something. Both are loud. That's the whole point of doing it.
And yeah, the $25 was never hosting.
I like the distinction between paying to build and paying to keep an app alive.
Those are two very different jobs, but they're easy to mentally bundle together because one tool handles both. Thinking about them separately makes it much easier to choose infrastructure based on where a product is in its lifecycle rather than where it was originally built.
"Choose infrastructure based on where a product is in its lifecycle rather than where it was originally built" — I'd add that this is genuinely hard to do, because everything is designed to push the other way.
Bundling isn't just a mental habit, it's the default path. Deploy is one button, inside the builder, right where you already are. Separating requires you to stop, decide, and do work. Staying requires you to do nothing.
That asymmetry is the whole pricing model. It doesn't need lock-in on the code when the default is already doing the job.
I'm glad it resonated.
Reading your reply gave me one thought about what changes once the default path becomes the product's biggest competitive advantage. I'd rather explain it in the context of what you're building than try to condense it into a few comments.
If you're interested, what's the best email to reach you on?
Link to my article about hosting a Lovable apps - https://livemy.app/blog/host-lovable-app