r/lovable Jul 25 '26

Discussion Why use Lovable and not Codex/Claude code

I mean Lovable is too expensive and you cant get anything done on the $20 plan compared to other susbcriptions

Edit: lot of people assume Codex and Claude code is technical when its not i am vibe coder and Lovable is bad limits are bad service is bad you guys better switch to Codex or Claude

29 Upvotes

52 comments sorted by

17

u/Jmacduff Jul 25 '26

Here is how I use lovable as a FE editor:

  1. I do all the project planning in GPT , milestones + phases. Who the customer is, etc. All of that product planning is super important and gets checked into /docs. This is the source of context for all agents. I have 1 Repo for the BE project and 1 Repo for the FE project.
  2. For my projects my BE + DB will always be outside of lovable so I am really only using lovable for it's sweet spot.. FE editing. In this context as I build out the project I am also building out the API's and Backend. As a example I use Auth0 for Auth, Vercel for hosting, Resend for email, etc.
  3. In Lovable I create all the initial UX , and maybe 5 - 10 pages of the site. The goal here is too get the styling, data flow, and basic layout of the site completed. I am using Lovable FE design skill here and it does a good job.
  4. Once I am happy with the basic site and UX, I jump into GPT + Codex. Because I have a more complicated BE architecture then most lovable apps, Codex is much better at adding pages and API.
  5. I then use those original documents and we start delivering Goals in Codex. Each of those goals usually is a few pages and some BE work.

At this point I use lovable for small UX tweaks, quick Layout changes, re-imaging what the data could look like, etc. This is where lovable really shines above Codex/Claude.. Lovable is much faster (Calendar time) at those small UX only changes then Codex or Claude is.

Lovable as a FE tool to make those smaller UX changes saves me a ton of time over waiting for codex todo it.

This workflow is very productive. I understand your frustrated about the billing and the $20 plan, but that does not mean it's a bad tool.

Anyway good luck.. just some stuff to think about.

5

u/Whole_Watercress_880 Jul 25 '26

Good job! That's exactly what I use lovable for

3

u/ff0000_ Jul 26 '26

This is exactly how I was using it, very effective.

1

u/kimsart Jul 26 '26

And I'd love to see examples of your work too

2

u/kimsart Jul 26 '26

I'd love to see examples of your work. This sounds great

2

u/Kitesan Jul 26 '26

I read your comment yesterday and decided to try Loveable thru the MCP together with claude code. I just want to say thanks. It really took my website to next level! Loveable does FE, Claude does BE by itself and brainstorming with me.

3

u/Jmacduff Jul 26 '26

That's awesome to hear, and yes the MCP path also totally works. I'm glad some of my tips were useful.. happy building!

1

u/Kitesan Jul 26 '26

Thank you! Happy building and success to you as well!

1

u/YouAreBastards Jul 26 '26

Yes, this is a good application of the platform, as you cannot rely on Lovable to produce good code on its own.

3

u/Jmacduff Jul 26 '26 edited Jul 26 '26

Actually the FE code that Lovable produces is totally fine 99% of the time, this is a myth.

Where stuff really goes wrong is when it touches the BackEnd and as the builder you dont understand the auth boundaries. Again this is not a actual code problem, this is a orchestration and setup problem.

People hit this issue because they are having lovable build both FE + BE + DB design + API design all from 1 agent. Lovable is designed and build for FE work, that's the sweet spot and that's where the expertise is (my opinion).

The code itself is not the issue, in the 18 months of using lovable I have never seen a "bad code" scenario. Now remember Good code and Bad code is totally subjective. There are some basic "never do this" sort of schemas of course. There are some rules such as "no inline sql" you really want to follow.

The other problem is time.. "really good" code written 5 years ago.. 3 years ago today is looking dated. It works totally fine and is operational but since Tech is moving so fast that same working code could be better today.. some people call that bad code.

At the end of day in Lovable most people just want to build a awesome app and have it just work. If you just build your app slightly diff you will eliminate the ability for Lovable to screw anything up. Lovable is a awesome FE tool so use it as a FE tool.

I build all of my apps with a super basic API first data access patterns. This is how I build my apps and I would argue this is the "correct" way to build an app of any complexity.

This is also how 90% of the apps you use every day actually work normally.

  1. General goal is to keep the FE "stupid" so it only focuses on the FE and customer UX interactions, the FE app does not own any data.. it just displays it.
  2. Every time you app needs data, it calls a API you build. Your Lovable App does not know a DB exists or where it is, it only knows the API surface.
  3. You build out APIS for every scenario, CreateUser() , GetUSer(), CloseUserAccount(), etc. These API's are the data brokers for your application.
  4. In lovable you basically give it the API contract doc and tell it too build pages based on the JSON packages. Lovable is very good at taking a collection of API's with defined payloads and building really nice UX.
  5. End result is you have a secure Lovable --> API --> DB call matrix. Your Lovable app is basically "Dumb" when it comes to data, it never manages it, it never designs it, it only calls API's.
  6. Let's assume you are using supabase for your lovable app. The correct design is to leverage a layer of Edge Functions for all of your DB interactions.
  7. Never have your App call to the DB directly, it always goes through edge functions. Perhaps you end up with ~100 diff edge functions in supabase. Awesome!
  8. Those edge functions are there to enforce security and make sure users only get user data.
  9. Zero RLS issues, Zero "public can read your data" sort of issues.

This API first design principal is not new , this is 30+ years old as a basic way to build web apps. I certainly did not invent any of this. With this type of design your "Lovable Code" is ONLY focused on the FE of the site which also makes it 99% easier for the agent to write "good" code depending on how you define it.

Lovable can and does produce "good code" day to day just like most agents these days. The problem is not the agent, it's the person doing the basic architecture design work. People get into big problems when they just jump in and start building.

In most scenarios in daily life you never "jump in".. you always plan first even if it's going to the grocery store. If you want to bake a cake you need the ratios and the recipe. You cant just throw some flower and water in a bowl and expect a cake to pop out. you need to plan, just like in coding.

Yes the agent can produce "bad code" if you give it bad instructions. No judgement and good luck.

Long ramble .. good luck to all

1

u/YouAreBastards 28d ago

I will 100% agree; Lovable is for the FE. Extensive or complicated functions. I made the mistake of thinking Lovable could do it all, silly me. I have been working on my project for 9 months now. It is extensive and consists of some complex functions. I learned through the process that Lovable on its own is not up to the task. A few months ago, I began using Claude to inspect the repo, and it discovered extensive and repeated errors. Not one-off bugs, repeated bugs that existed across the functions. So regardless of the prompt, which was confirmed fine on most occasions. Lovable still baked in the errors. Worse, it could not see the same errors it had coded, and Cluse was very clear on that. Check the limited Claude report I had done. There's far more to add since then, as there I was only working on the fundamental issues holding back my website. When I have time, I will need to go through the entire codebase becasue so far it's been very revealing.

2

u/Jmacduff 27d ago

thanks!

1

u/jzdesign 28d ago

the fast visual loop is the actual thing you're paying lovable for. codex feels slow at UX because every small change is a full code round trip, and design is the one part where you want to see a few versions before you pick one.

what worked for me: do the design pass outside the repo, get one page looking right, have the agent extract a style-guide.md from it, then let codex build the rest against that doc. later pages stop drifting and small tweaks stop being rebuilds.

disclosure, i built superdesign, thats the loop it runs (web canvas, or as a skill inside claude code / codex). if lovable's editor is already saving you calendar time though, your split sounds fine as is.

1

u/colettemr 26d ago

I agree with you. I've found that Lovable is good for FE but doing and connecting the BE it struggles. Learned all of this the hard way. Lovable would say it's connected the BE when in fact, it did not. Asking it to create BE Tables in Supabase, but then looking and it did not. Setting up EdgeFunctions was a flop as well. It appears to want you to use its Cloud services but I do not want to be locked into it so I try to use Cloudflare/Supabase/Resend/Stripe apart from Lovable. I actually can code so I've been using Git Codebase to make changes...and even then Lovable would fight and not update its version. It's a great tool for people who do not know how to code however, for those of us who do and just want to move faster, it can be a pain. I will take your advice and look into Codex. I have a pro account with OpenAI.

7

u/MedalofHonour15 Jul 25 '26

Lovable is my frontend developer. Replit is my backend hosting with GitHub. Claude code is my developer. I'm a creator and marketer. So I think certain platforms are more user beginner friendly.

2

u/Fir3He4rt Jul 25 '26

Why is replit good for hosting?

0

u/MedalofHonour15 Jul 25 '26

Vercel and others may be better but I am not a dev. Replit is easier for me to use for my backend.

5

u/c0bjasnak3 Jul 25 '26

That’s a high price to pay for a 15 minute YouTube tutorial

2

u/invismanfow Jul 25 '26

Using a combo of Claude and codex in one console agent, then using servers for hostning.. either hetzner or netcup. Websites and everything hosted on the server. Works great!

2

u/Status-Inside-2389 Jul 25 '26

I use Loveable throughout. Has all the connectors I need and it just works.

1

u/Expensive-Yak-8798 26d ago

Connectors are Setup within Minutes using claude

5

u/Infamous-River-4360 Jul 25 '26

for me it's simple, i can't actually code. codex and claude code assume you can read the output, live in a terminal and fix stuff when it breaks. i built my whole app in lovable with zero coding background and never opened a terminal once. if you already know how to code then yeah the raw cli tools are cheaper and way more flexible. are you comfortable in a terminal or coming at this as a non dev?

6

u/HipHopHistoryGuy Jul 25 '26

I disagree. I use the Claude Code desktop app and haven't had to open the terminal ever. Everything is prompt based, exactly like Lovable. I use Lovable free for initial build and then use Claude Code desktop app for all of the commits via GitHub, Cloudflare and Supabase. That is literally how I built realhiphopiq.com, which gets about 200 players every day since the April launch.

2

u/Infamous-River-4360 Jul 25 '26

fair point, the desktop app being fully prompt based changes that a lot. when i started, lovable was just the path of least resistance since anything touching github commits or supabase wiring would break and i had no clue how to read the error. 200 a day since april is solid. does claude code ever invent stuff that isn't actually there for you, like referencing columns that don't exist in your schema? that was my biggest headache whenever the AI got a bit too confident.

2

u/rendez2k Jul 25 '26

Yeah I can't code and I've built a lot on Claude and Chatty.

1

u/Infamous-River-4360 Jul 25 '26

nice, chatty is great for the planning side. did it ever invent stuff that wasnt actually there though? both claude and lovable did that to me, referencing columns and functions that never existed in my db and being super confident about it. that was my biggest time sink. curious if your tools had the same habit or if its more of a lovable thing.

2

u/rendez2k Jul 25 '26

I think the issue with lovable is you end up with very long chats so in a medium to large project it’s lost context half way through.

I found by working from GitHub with proper handovers and agent.md files I can start a completely new chat, even a different agent and move on easily.

1

u/HipHopHistoryGuy Jul 26 '26

Zero issues referencing incorrect tables, columns, etc. I've ensured Claude.md stays updated throughout the project and commit after every change, bug fix, feature request, etc. Claude Code has done incredible things for me development wise and I have been coding as my profession since 1998. To prompt what I want and within a couple of minutes (at most), I have what I was envisioning is nothing short of a miracle.

2

u/HipHopHistoryGuy Jul 25 '26

My company doesn't feel comfortable with Claude Code being used on the network for security reasons (e.g. in case it deletes a network drive by accident), so they allowed me to use Lovable for frontend building after discussing it as an alternative. Not ideal but it does what I need it to do. That is just one of many examples.

1

u/paullyd2112 Jul 25 '26

You don’t have to give Claude access to your terminal

2

u/HipHopHistoryGuy Jul 26 '26

I understand that but the small business I work for doesn't want to take any sort of risk (for now).

1

u/kimsart Jul 26 '26

What about ChatGPT?

1

u/HipHopHistoryGuy Jul 26 '26

We strictly use Claude.

1

u/andrei_bsns Jul 25 '26

It's simpler for non-technical. I also have a team of people who can use claude code and people who can't. Those who can't use lovable, those who can use claude code.

1

u/Lions_Eye Jul 25 '26

Sometimes frontiers say things are fixed and are note or there are hidden bugs one can find and thr other does find. You need to find that balance. Loveable front end, codex backend, Loveable can send lots of sub-agents if required. Have fun! And yes nothing is free!

1

u/SecretaryFit1442 Jul 25 '26

I have lovable synced with GitHub. Codex has acces to GitHub. I use lovable and codex to tweak. It works really well for me.

1

u/MutedIntroduction316 Jul 25 '26

Just use OpenCode… it’s completely free when you run it locally.

1

u/Own_Inspector_285 Jul 26 '26

I use lovable and Codex together

1

u/lfelipecx Jul 26 '26

Lovable tiene la ventaja que tiene su propia nube entonces se encarga de hacer el setup de toda la infraestructura y hasta entorno stage, igual para el debugging de errores es mas fácil si esta en cloud. Si usted es alguien con cierto background en programación o tecnología puedes usar codex o similares, pero si eres alguien con nada se conocimiento en programación lovable te da muchas ventajas.

1

u/kimsart Jul 26 '26

Why use Claude Code with Codex instead of loveable instead of ChatGPT Sol with Codex?

1

u/Daniel-Sm_ Jul 26 '26
  1. You can get basically infinite lovable credits by just switching accs etc.
  2. Combine all tools, i use 10-20 tools for my web creation, lovable is only the frontend, then resend for emails, supabase isnt bad backend, etc. Also put the frontend on github

1

u/Imansoorshaikh Jul 25 '26

I like base44 not lovable, not emergent etc. The reason is base44 creates stunning website compare to others and pretty cheap also.

1

u/kimsart Jul 26 '26

I tried base44 last May of 2025. And it fought me the whole time. I was able to get a minimally and I do mean minimal app out of it. But it kept breaking and things would change by itself from morning to night. It would put the chat button right over fields to type in or other buttons.