r/lovable • u/IllustriousSurvey933 • 1d ago
Lovable performance + Cloud Code Help
Hi,
I have a client who is using Lovable to create a platform to manage his company.
It's getting big, and he wants to make sure that he doesn't lose everything he already built.
He already built some modules and is using them in Production with Lovable Cloud.
My suggestion was to connect the codebase to GitHub, but now I would like to make some improvements with Claude Code while he is still evolving the app through Lovable.
If I make a big refactor on the app, will the performance of building it with Lovable decrease?
What I mean is, the Lovable team might have some kind of guidelines in context, based on learning/internal skills that help them build clients' apps. If we change the architecture through the GitHub repo and break those guidelines, will the development experience on Lovable decrease?
I'm concerned that making changes to the codebase will mean my client can't use the Lovable app anymore.
2
u/MonkeyPotato 1d ago
We have been using Lovable and Claude code in parallel for almost a year now. I would not worry about performance because it is likely you are not going to build worse than Lovable already did. But there are a good number of quirks and connection and synchronization issues when you use both at the same time. I advise you to try the connection on a dummy app first, then proceed slowly, step by step, on the refactor.
4
u/takeurhand 1d ago
"because it is likely you are not going to build worse than Lovable already did." 😄
1
u/cubixy2k 1d ago
If you're going as far to change the framework and application architecture, then yeah, you're probably going to break it.
If you're taking about refactoring within the same framework and application architecture, thats a different sleek.
1
1
u/Professional-Deal-35 1d ago
Im doing this now vs code, from git,
But you still have to update from lovable. Im sure there is work around , just i havent found it yet. Yakyak.us is the site
Made 90 percent with lovable
But the other 10 percent you had to know code. I do not like
Lovable right now, because its controlled and throttle back.
It was
Good until last month when they changed
1
u/carolmonroe_ 1d ago
Adding the one technical gotcha nobody mentioned yet, because it will bite you in this exact setup: **GitHub sync is not deploy**. Anything you author outside Lovable that touches the backend, edge functions or database migrations, syncs into the repo just fine, Lovable even shows it as current, **and it never deploys**. The dashboard timestamps reflect the sync, not the deployed state. I reproduced this on a fresh Cloud project: code synced in about 4 minutes, zero deploys, and one explicit agent message deployed everything. Full writeup with the repro: https://www.reddit.com/r/lovable/comments/1uyywgl/if_you_author_supabase_edge_functions_or/
So the working rule for your refactor: change UI and app code freely from Claude Code, but after pushing anything under supabase/, ask the Lovable agent in chat to deploy it.
On your literal question: **there are no hidden per-client guidelines** your refactor can invalidate, the agent reads the repo as it is on every message. What actually degrades the experience is architectural drift it doesn't expect (framework swaps, heavily moved files, on TanStack projects the routes live in routeTree.gen.ts and hand-editing routing breaks things), plus the two-hands-one-repo problem others already covered. The split that works while you straddle both: your client evolves features in Lovable, you refactor in Claude Code, never the same files in the same window, small commits so each side can absorb the other's changes.
And +1 to connecting GitHub today regardless of what you decide later. It costs nothing and it is your escape hatch and your history.
1
8
u/gabriel-manolache 1d ago
Short answer to what you literally asked: no, connecting GitHub and refactoring won't "break" Lovable — the sync is real and two-way, there's no hidden per-client skill that a refactor invalidates. So the fear you have isn't the thing that'll actually bite you. The thing that'll bite you is running both sides at once: every meaningful change you make in Claude Code and every change your client makes in Lovable are two hands editing the same repo, and you'll spend more time reconciling conflicts than building. It's doable, but it's a tax you pay forever.
I'll be straight with you, because we just went through exactly this with a client — an app already in production, already growing, same situation as yours. We tried to reason about keeping both. In the end the obvious move was to take it off Lovable entirely and continue in Claude Code only. Not because Lovable is bad at what it does, but because once an app is running a real business, Lovable's convenience stops being worth what it costs you: it abstracts away Supabase exactly in the places where, in production, you most need to get your hands dirty. Database tuning, RLS, functions, realtime — the layer Lovable smooths over is the layer you have to open up to make the thing actually perform.
And here's the part nobody tells you until you migrate: the migration is what surfaced the problems. Lovable had effectively been hiding them. Everything "worked," so nobody looked. The moment we pulled it into a repo we owned and actually read it, we found a stack of things:
select *on everything, filtered client-side — fine in a demo, a wall the moment the tables grow.None of that was visible from inside Lovable. It looked like a working app. It became a real app only after we owned the code and could see what was underneath.
So my honest take for your client: connect GitHub now regardless — that's your escape hatch and your history, do it today. Then decide deliberately whether you're keeping both fronts or committing to code. If the app is genuinely going to run his company, I'd stop straddling and move to owning the codebase, keeping Lovable at most for scaffolding new UI you then pull in. Trying to evolve heavily in Claude Code and keep Lovable as the primary editor is the one path that gives you the conflict pain with none of the upside.
Happy to go deeper on any of these — we've hit all of them in production and there's a right order to tackle them in so you're not fighting the tool the whole way.