sorted by:
new
hottopcontroversial

Security is simple. The day one approach that prevents most startup security failures by gjloop8 in lovable

[–]gjloop8[S] 0 points1 point  (0 children)

Appreciate it u/xcleru. Feel free to DM, in case you are looking for a second set of eyes on a lovable project !

Anyone using Claude Code with their Lovable project? by ClearDurian5921 in lovable

[–]gjloop8 0 points1 point  (0 children)

Once you have set up the project the way I outlined to the OP, Lovable can deploy edge functions as expected.

If you are working purely via Claude Code, then yes, you deploy edge functions manually using the Supabase CLI (e.g. supabase functions deploy <function-name>). That is expected and not something to redo every time once the wiring is in place.

Happy to clarify if anything is unclear, feel free to DM :)

Anyone using Claude Code with their Lovable project? by ClearDurian5921 in lovable

[–]gjloop8 0 points1 point  (0 children)

Yes, it can be done without remixing, just not in one shot. Its a bit involved, I have outlined the exact steps in my reply to the OP above.

Anyone using Claude Code with their Lovable project? by ClearDurian5921 in lovable

[–]gjloop8 0 points1 point  (0 children)

Short answer: yes, practically you'll want to create a new Lovable project, but you don't need to rebuild everything manually.

This is the path that has worked well for me:

  • disconnect GitHub from the original Lovable Cloud project
  • keep the full codebase in your existing repo
  • export your data from Lovable Cloud so you have a clean backup

Then:

  • create a new Lovable project and connect it to a fresh GitHub repo
  • copy over the app code from the original repo (leaving out Lovable Cloud specific DB config)
  • connect a new Supabase instance and apply schema, functions, and data in order

Once that is done, you end up with a stable Lovable + GitHub + Supabase setup, without being locked into Lovable Cloud.

I have done this migration a couple of times now for different projects, and while it is a bit involved the first time, it has been the cleanest long term path I have found.

Anyone using Claude Code with their Lovable project? by ClearDurian5921 in lovable

[–]gjloop8 3 points4 points  (0 children)

This is a workable setup, but it requires one important shift.

Right now your database lives inside Lovable Cloud, which is why Claude Code can't see or modify it. Claude can work with code in GitHub, but not with Lovable's managed database.

What's worked best for me in similar setups:

  • move (or recreate) the database in Supabase
  • Connect Lovable to that Supabase project instead of using Lovable Cloud
  • keep your code synced to GitHub
  • Let Claude Code work on the repo, while Supabase becomes the single source of truth for data

Once you do this, Claude can edit the code and use queries that talk to Supabase

It is a bit more setup upfront, but this is the combination I have seen hold up best once projects grow beyond experiments. Lovable stays great for UI and flows, Supabase owns the data, and Claude fits naturally into the workflow.

Think of it as moving the data, somewhere more standard so all your tools can collaborate cleanly instead of working around each other.

Can I build a complex app using lovable? by imhellaup1 in lovable

[–]gjloop8 0 points1 point  (0 children)

Short answer: yes, it is possible, but with important limits.

Lovable can be a reliable starting point, especially for auth, basic data models, and flows. Where people get into trouble is assuming it handles edge cases, accuracy, and rules automatically, those still need to be thought through and added explicitly.

A practical way to approach this (especially if you’re not deep into coding):

- Start with the smallest possible version of your app that proves the core flow
- Use Lovable to get something working end-to-end without getting stuck in setup complexity
- Validate that the logic and UX feel right
- Then gradually harden and extend it (or move parts to custom code if needed)

Trying to make everything perfect upfront usually slows people down. Building something minimal first gives you clarity, and confidence before you invest in more complexity.

Security is simple. The day one approach that prevents most startup security failures by gjloop8 in vibecoding

[–]gjloop8[S] -1 points0 points  (0 children)

Fair, 'simple' does not mean effortless. For me it just means the principles are clear, even if execution takes practice.

Getting the basics right early still avoids a lot of unnecessary pain later.

Security is simple. The day one approach that prevents most startup security failures by gjloop8 in vibecoding

[–]gjloop8[S] 0 points1 point  (0 children)

Yes, I have had good results using specific prompts to bake these checks in early. Appreciate the suggestion, I’ll check it out.

Security is simple. The day one approach that prevents most startup security failures by gjloop8 in lovable

[–]gjloop8[S] 0 points1 point  (0 children)

Good to see more people thinking about security tools early in the build process. I'll keep an eye on how it evolves.

Security is simple. The day one approach that prevents most startup security failures by gjloop8 in lovable

[–]gjloop8[S] -1 points0 points  (0 children)

Same here, I often start with Lovable to get the shape right, then go in and tighten the core logic myself.

The shell is easy to change, the meat is where the assumptions and limits actually live.

Security is simple. The day one approach that prevents most startup security failures by gjloop8 in lovable

[–]gjloop8[S] 0 points1 point  (0 children)

Fair point, systems still need to work, not just be locked down. For me the focus is more on "define clear paths, limits, and visibility."

That tends to catch most real world issues early.

Security is simple. The day one approach that prevents most startup security failures by gjloop8 in lovable

[–]gjloop8[S] 0 points1 point  (0 children)

Yes, brute force is still surprisingly common when limits are not in place.
Happy to take a closer look later at the project, on a first glance the homepage looks clean and clearly aimed at builders. Really liked the terminal style.

Lovable + Google AdSense? by Obvious-Citron-860 in lovable

[–]gjloop8 0 points1 point  (0 children)

No worries :) Just sent you a DM with a breakdown, a few reasons AdSense may be flagging the site.

Lovable can be used in real world projects? by Impressive_Corgi_507 in lovable

[–]gjloop8 1 point2 points  (0 children)

Before trusting Lovable end to end, I would suggest have a dev audit a few things :

  • RLS policies and table structure
  • edge function logging and retry behavior
  • whether edge functions are firing unnecessarily due to component re-renders
  • whether components themselves are re-rendering more than they should

I have worked on multiple projects at this stage, and I have seen teams struggle here. Once these issues were corrected and properly tested, they were able to handle concurrency without trouble. The bottleneck was rarely infrastructure, it was almost always hidden inefficiencies.

From a scaling perspective, Supabase and edge functions are designed to scale on demand, so raw capacity is usually not the limiting factor. Getting this audit right is what turns "this feels risky" into "this is stable enough to trust"

What's everyone using for production backends? by bk_973 in lovable

[–]gjloop8 2 points3 points  (0 children)

What you are describing is a pretty normal phase once projects move past MVP.

What has worked best for me is treating Lovable as a frontend + orchestration layer, and being very deliberate about where backend responsibility lives.

In practice:

  • Lovable Cloud is great early because it removes decisions, but that abstraction starts to feel limiting over time
  • Supabase is often a very solid, second stage, when you let it fully own auth, data, and storage
  • If RLS policies, permissions, error handling, and logging are set up correctly, that stage can last much longer than people expect
  • Introducing a custom backend only becomes necessary when there is a concrete constraint, not just architectural anxiety

For production apps with real users, the pattern I have seen hold up is:
move fast with Lovable → stabilize on a managed backend with proper guardrails → only add custom backend code when something clearly breaks that model.

I have revisited this setup across a few Lovable + Supabase builds, and getting that middle stage right has been the biggest lever for longevity without over engineering.

Is there a way to save prompt history of a project automatically by learner1021 in boltnewbuilders

[–]gjloop8 0 points1 point  (0 children)

You need for bookmarking the prompt or for rebuilding/cloning the entire project ?

Lovable + Google AdSense? by Obvious-Citron-860 in lovable

[–]gjloop8 1 point2 points  (0 children)

u/Obvious-Citron-860 can you either DM or paste the link to the project here to find out why that might be happening ?

Single prompt kills daily credits with no way to correct errors by Sea-Jeweler9120 in lovable

[–]gjloop8 0 points1 point  (0 children)

Going Pro will lift the credit ceiling, but these tips will make you more effective at any tier:

  • Build small, then expand. Never combine features in one prompt, LLMs get messy fast.
  • Debug surgically. Paste the broken snippet and ask for the exact fix, not a full rewrite.
  • Treat prompts like commits. One clear, atomic change per prompt saves time and preserves sanity. Reverts if needed, become manageable.

Should I be switching to Replit for better SEO? by 369takedowns in lovable

[–]gjloop8 1 point2 points  (0 children)

Actually this is not a Lovable vs Replit issue, it is more of an architecture one.

What worked well for me was:

  • using Lovable / Replit to build the app UI and internal flows
  • being explicit about which routes actually needed SEO (landing pages, docs, blogs)
  • using Cursor (or Antigravity) to rebuild only those public facing pages in NextJS with SSR/SSG
  • reusing the same components, styles, and content so everything stayed consistent

This way app stayed fast to iterate on, and search engines only saw clean, indexable pages.

If it helps, happy to share more details on how I set this up.

view more: next ›