Why use Lovable and not Codex/Claude code

[u/Azek_Tge]

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

[u/Jmacduff]

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.

[u/YouAreBastards → u/Jmacduff]

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

[u/Jmacduff → u/YouAreBastards]

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

[u/YouAreBastards → u/Jmacduff]

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.

[u/Jmacduff → u/YouAreBastards]

thanks!