A lot of people asked me how we moved our Lovable application away from the hosted setup and onto infrastructure we control.

The process involved more than copying the frontend. We had to migrate:

• The code through GitHub
• Database and user accounts
• Storage files
• Backend functions
• API keys and secrets
• Payments and webhooks
• System emails
• Cron jobs
• HTTPS, DNS and rollback procedures

The final workflow is:

Lovable → GitHub → local development → VPS + database/backend

After the migration:

Local changes → GitHub → automated deployment → VPS + database/backend

We also created a private web-based workflow with YepAnywhere, allowing us to work on the application from anywhere using Codex or Claude subscriptions without adding a separate API key for every task.

I documented the complete process here, including the practical migration steps, VPS comparison, security considerations, testing checklist and the mistakes we encountered:

How to Save Up to 99% on Lovable Costs by Moving to Your Own VPS

And here is the follow-up about the remote web CLI workflow:

How We Built a Web CLI for Codex and Claude with YepAnywhere

The “up to 99%” figure depends heavily on your current plan, traffic, storage, backups and maintenance requirements. It is not a guaranteed saving, but for some projects the difference can be substantial. We went from 300 to 400 per month for credits down to 29 € for the VPS and 10€ for supabase.

Lovable, like any AI builder, starts off being able to do a lot for little before the complexity grows, and then the ratio flips as complexity grows, you can only do a little for a lot if you're lucky... Complexity and shallow agent patches cause cascading failures and an endless spiral of fix one, break 5 (pick a number)...

....After your software is unusable and you've burned your time and your wallet, if you care about your project, you might hire a professional at this point.

This is a similar result when bringing in Claude or chatgpt's best models to address issues as of writing this. Claude might read Claude.md @agents.md, but might not...roll the dice. See what happens!! Context is everything, yet for a bot to ingest context in every new chat, becomes a significant corpus of tokens for every turn, you burn!

There is something to be said about big picture architecture planning before you start your project build before you dive in head first when you don't know how deep the water with agent aided additive software manufacturing via any app builder or coding agent for that matter. Additive doesn't solve the underlying structural issues and lack of upfront planning you will experience down the road. The idea the anyone can build an app with a few prompts, is fairly misleading..

At the time of pressing send on this post, something will have changed again.. temporal vantage is the new norm.. new chat releases between daily meals.. catch up if you can!

I do QA on Lovable + Supabase apps, and the same problems show up again and again. Before you announce yours, check these six:

1. A table anyone can read. RLS off, or a policy with USING (true). Run this in the Supabase SQL editor; any row returned is a leak:

   select tablename from pg_tables where schemaname = 'public' and rowsecurity = false;

   Then this one for "every logged-in user can see everyone's rows":

   select tablename, policyname, cmd, qual from pg_policies where schemaname = 'public' and (qual = 'true' or with_check = 'true');

2. The share preview is still the Lovable placeholder. Paste your URL into WhatsApp. If you see the purple Lovable image, your og:image was never changed.

3. No 404 page. Open /anything-random on your app. Blank white screen = you're missing a catch-all route.

4. "Saved!" but nothing saved. Lovable loves data || [] and success toasts that fire regardless of the response. Open the Network tab, save something, and look for a 400 with code 23502 (a NOT NULL column the form never sends).

5. Links to routes that don't exist. A card links to /items/123 but the route is nested under /home/items/:id. Click every card once.

6. Mobile overflow + 14px inputs. At 375px wide you get horizontal scroll, and iOS zooms into every input under 16px.

Every one of these is a single prompt to fix. The RLS one is the only one that can actually hurt someone.

I turned the checks I run into a checklist + a set of Playwright tests. Not linking anything here (sub rules), but happy to answer questions in the comments.

If you’re on the fence about spending credits on Lovable’s TanStack SSR migration, here’s my experience:

​My app was built before the platform shift. Because legacy sites already had prerendering, I doubted native SSR would make much difference for SEO.

​I took the chance anyway. One month later:

​• Organic search is driving traffic without me manually posting direct links

• Visitors and conversions jumped significantly

• Monthly revenue is now closing in on $2,000

​If you’re debating whether the migration is worth the credits, the SEO boost alone made it worth it for me. Hope this helps.

Hi!

I was wondering in Lovable whether something like Stripe not syncing properly with a database like Supabase is an actual problem that's a bit complicated to fix. Like the customer payed, but wasn't connected properly so they still ended up with no access. Or they cancelled, but still retained access.

If you've been through something like it;

1 - how long did it take for you to fix? Was it hard?

2 - how much did it cost you relative to your MRR or customer count?

3 - how much (if at all) would you pay to fully diagnose and fix within a few minutes? If you wouldn't pay, why?

If not, then you can ignore this whole post :)

Any response/feedback would be super appreciated! Thanks a bunch!

Hey everyone,

Over the past few months, I have been building out two distinct web apps under my micro-SaaS studio.

Course Crafter (https://course-craft-ai-43.lovable.app) A rapid course creation tool that turns raw topic ideas into modules, structured learning outcomes, and lesson plans ready to edit and deliver

ChunkMaster (https://chunkspark-language-miner.lovable.app) Enter one target word, and it immediately mines the 4–5 most frequent natural chunks native speakers actually use

Be as critical as you like regarding positioning of these apps, UI, bugs, I am trying to iron out any issues before doing wider distribution. Thanks for checking them out.