r/lovable

Been using Loveable for a few months now and genuinely love how fast I can go from idea to working app. But I keep hitting moments where I think — "okay, this is where I need something more surgical."

Curious how others here actually work in practice:

Do you use Loveable as your entire stack, or do you layer in tools like Claude Code, OpenAI Codex, or similar agentic coding assistants alongside it?

My current experience: Loveable is incredible for spinning up UI, scaffolding, and rapid iteration. But when I need to dig into complex logic, refactor a messy module, or debug something subtle, I find myself wanting a tool that can reason over my codebase at a deeper level.

Some specific questions I'm wondering about:

• Do you ever export your Loveable project and then hand it off to Claude Code / Codex for heavier lifting?
• Or have you figured out prompting strategies inside Loveable that make external tools unnecessary?
• Is the "vibe coding only" approach actually viable for production-level projects, or does it have a ceiling?

Would love to hear real workflows, not just theory. What's actually working for you?

For the first two weeks I was building like most people do:
“Add a dashboard”
“Now add a chart”
“Now add filters”
Everything worked. But nothing fit together. I kept rebuilding the same sections because the overall structure wasn’t clear — to me or to Lovable.
Then I tried something different. Before touching Lovable, I wrote a full PRD — product requirements document. Nothing fancy. Just:
— What problem does this solve
— Who is the user
— What are the core features (prioritized)
— What does each screen do
— What are the user flows
Then I pasted the entire PRD as the first message in a new Lovable project.
The difference was immediate.
Lovable started making decisions that were consistent with each other. The navigation made sense. The data model fit the features. I stopped rebuilding things I’d already built.
The prompts after that were small and specific — “build feature 3 from the PRD” — instead of explaining context every single time.
Three things I learned:

1. Lovable is only as good as the context you give it. A PRD is context.
2. The PRD doesn’t need to be perfect — it needs to be clear about priorities
3. You will change the PRD as you build. That’s fine. Update it and re-paste.
   If you’re rebuilding the same feature more than once, you probably don’t have a Lovable problem — you have a clarity problem.
   Anyone else using PRDs or similar docs before starting a build?

I looked into making a change (in Plan mode), realized that the changes I was thinking about had already previously been done. So instead of continuing I told Lovable "No change".
Lovable took 1 credit for the planning (no issue with this - although a little high IMO) but then when I told it "no changes" it used a whole credit to confirm that there were no changes!

I've also been seeing the credit usage increase 2-3x in the past weeks.

Time to move on... Lovable is doomed if it thinks it can compete with the other LLMs at this stage. Sure it can make things easier for non-techies but the LLMs are now very good at helping with step-by-step instructions when it comes to database, email etc.

I’m building a new application for a group, helping them transition from Cognito forms that feed Make then Google Sheets to use a a Supabase database with forms built by Lovable. The forms they currently have are linked from a website that’s open to the public and they don’t use any human verification or Captcha. In the new design I’m contemplating adding it to prevent spamming or other malicious activity, but I know I’ll probably get some pushback on it from the group.
The forms are mostly for signin to events and referrals. Not high traffic right now, but growing.
Just curious what the consensus is here, verifyication/captcha or no?
Or, if there’s another solution I’m not aware of.

View Poll

4 weeks ago I had an idea. Today it’s live with real users.
Here’s what actually happened in between the parts nobody posts about:
Week 1: Everything looked perfect in Lovable. The UI was clean, the flows made sense. Then I connected Supabase and realized I had no idea how auth actually worked.
Week 2: Built the core feature. Worked perfectly in dev. Broke completely in production. Spent 3 days on a bug that was one missing environment variable.
Week 3: Added Stripe. Thought I’d finish in a day. Took a week. Not because Lovable was hard because payments touch everything.
Week 4: Launched. First user signed up within 48 hours.
What Lovable is genuinely good at: moving fast on UI, iterating without breaking things, letting non-technical founders build real products.
What it doesn’t do for you: thinking through your data model before you build, handling edge cases in complex API integrations, making product decisions.
The honest take: if you treat Lovable as a tool that executes your thinking, it’s incredible. If you treat it as a replacement for thinking, you’ll rebuild the same thing 4 times.
What’s the biggest non-obvious lesson you learned building your first Lovable project?

does loveable actually answer support tickets? does anyone know the timeframe? got a serious issue and haven't heard from a real person yet for days

Hi all,

Just wanted to make sure that my landing page tells the people what we are trying to achieve and what we are all about:

https://horizon-hues-forge.lovable.app/

Please do let me know what you think and if it makes sense to you!

ok so this is the inverse of every "i migrated off lovable" post you keep seeing. in case youre also lost on which tool is correct.
quick history. moved my main project from lovable to claude code in november. genuinely had real reasons at the time. credits got expensive, i wanted more control over backend logic, claude code is just more powerful for complex stuff.
5 months in claude code. ship velocity dropped maybe 60%.
yes the agent is better at deep work. no the agent is not better at "lets add a pricing card and link it." that was 3 prompts in lovable. that was 18 prompts in claude code, because claude code wanted to discuss the right abstraction for a pricing card component and i wanted to ship.
then opus 4.7 landed in lovable on apr 24. i tried it on a new feature for the same project. just to see.
it was so much faster than what i had been doing.
Like, embarrassingly. The thing that took me a full saturday in claude code took me 90 minutes in lovable.
now im running both. claude code for backend stuff that needs careful thinking. lovable for everything else. probably 80/20 lovable.
what i think most people get wrong about the migration question:
claude code is not "the upgrade." its a different tool for different work
lovables ceiling is higher than 6 months ago because of plan mode + workspace knowledge + opus 4.7
if your project is "saas with a normal-shaped frontend" lovable is probably correct
if your project is "weird backend with custom infra needs" claude code is probably correct
if your project is both, dont pick. use both.
would i make the original migration again? probably not. i overweighted credit cost and underweighted speed cost. credit cost shows up on a dashboard. speed cost shows up in the form of "its been 4 hours and i havent shipped anything."
anyone else come back? curious if im the only one doing this or if its a quiet trend.

has anyone switched from lovable to base44 and not look back? Been seeing some videos about this but i haven’t really looked much into base44 tbh

Hi everyone,

I have zero coding experience, but I need to build a responsive web app (PC, tablets, and mobile) for an industrial workshop and inventory management system.

The app needs to handle:

• User roles (Admin, Technicians, Warehouse, Accounting).
• QR code generation and scanning via mobile camera for parts and equipment.
• Moving stock from a General Warehouse to independent sub-warehouses.
• Work orders tied to equipment and service history.
• Data connection to Power BI/Excel (and eventually SAP B1 via API).

Crucially, I want to avoid vendor lock-in and be able to export the code (GitHub) if needed.

Given the relational complexity of the inventory, is Lovable the ideal choice for a beginner to build this step-by-step, or will I hit a wall?

Thanks!

I’ve been wondering lately if Lovable is just chasing its own tail. Let me explain: the more I try to hunt down bugs and fix them, the more new ones keep popping up every single time... I’m starting to wonder if, after fixing something, its next "fix" ends up breaking the fix it just made. If you know what I mean?

Like many here, I built an app and got it published in the Apple app store but faced the issue of marketing. I created a free blogger site (mistake) and used Gemini to make it look like my app, and then started writing various blog posts that at least did get indexed quickly on google. The problem was that the site looked really crappy and was a pain to update, since blogger was created back in the dark ages.

Fast forward to this week, and thanks to Lovable's massive SEO upgrade for new projects, I asked Lovable to build me a SEO friendly website on another domain I own at kyndrid.co.uk (kyndrid.app is the main site for the web app, but I had previously redirected kyndrid.co.uk to the blogger site).

Anyway, 10 mins later, I had a fully functioning site, same look and feel as the app, with an admin section for me to create new (hopefully SEO friendly) blog posts.

Once that was done, I redirected my custom domain away from blogger to my lovable domain and that was that.

I'll give it a couple of weeks and post an update on what (if any) traffic I see from google, if folks are interested.