G2

Luca P.

Chief Operations Officer DEQUA Studio | Formerly CTO in MarTech

Marketing and Advertising

Mid-Market (51-1000 emp.)

5/21/2026

"A fast way from prompt to working MVP, once you learn how to spend credits wisely"

4.5/5

What do you like best about Lovable?

The chat-driven build loop is the part I open every working day. I describe what I need, the screens, the data model, the basic flow, and within minutes there is a working React app I can click through. That speed used to be the marketing pitch I rolled my eyes at, but after months on the tool it is genuinely the workflow I trust for first-pass builds. The prompt-to-prototype cycle that used to take me a full afternoon of scaffolding now happens before lunch, and the output is something I can show a client without apologizing for what it looks like.

The Supabase integration is what makes Lovable feel like a real full-stack tool rather than a frontend generator with extra steps. Auth, the PostgreSQL database, storage, and edge functions are all wired up through the same chat interface I use to build the UI. When I say "add user login with email verification" the integration handles the schema, the policies, the redirect URLs, and the table setup without me touching a config file. I have built three internal tools where the entire backend lived inside Supabase, and the Lovable chat understood the table relationships well enough that I rarely had to drop into the Supabase dashboard to clean up after it.

Code ownership through GitHub is the feature that closed the deal for me. Every project syncs to a GitHub repo from the first commit, and the code that lands there is React with TypeScript and Tailwind, structured like a project a real engineer would ship. When a project outgrows the chat workflow, or when a client wants their developer to take over, I hand off a repo that compiles, deploys, and reads cleanly. That has been the difference between Lovable being a toy and Lovable being part of my actual delivery pipeline, because no client wants to inherit code they cannot maintain.

Visual Edits is the quiet feature that saved me more credits than anything else once I figured out how to use it. Text changes, color tweaks, font swaps, padding adjustments, those all happen in the visual editor without consuming a credit. I started routing every cosmetic change through Visual Edits and reserving the chat for structural work, and my monthly credit burn dropped by roughly half. Anyone evaluating the platform on price should weigh this carefully, because the credit math reads very differently once you stop sending the AI a prompt every time you want a button to be slightly bluer.

One-click deploy with the option of a custom domain is the part of the workflow that closes the loop with marketing teams. I have stood up a campaign landing page, attached a domain, and had it taking form submissions inside an hour, with no DNS panic and no scrambling to find a hosting account. The Lovable subdomain is fine for internal sharing while I work, and the custom domain swap is genuinely a couple of clicks once you point the DNS records. For pages that need to ship the same week they were briefed, that loop is hard to beat.

The chat interpreter has gotten noticeably sharper over the months I have used it. Early on, a prompt that asked for a multi-step form with conditional fields could come back with something close, but not quite right, and the cleanup was real work. Now the same prompt usually lands the first time, and the model is better about asking a clarifying question when the request is ambiguous rather than guessing wrong and forcing me to rebuild. I cannot tell whether that is model upgrades or product changes around how prompts are routed, but the result is fewer wasted credits and less frustration.

The integrations beyond Supabase have been a pleasant surprise. Stripe payments, Clerk for auth when I want something heavier than the Supabase auth defaults, OpenAI for any in-app AI features, all of those connect through the chat with credentials pulled from a settings panel rather than pasted into source files. On a recent project I wired up a paid waitlist with Stripe in under thirty minutes, which is the kind of thing that used to mean a Saturday of API documentation reading.

The build cadence of the product itself is also something I notice. New features land regularly, the changelog reads like a team that is actually shipping rather than polishing, and a fair number of the rough edges I hit early have been addressed by updates since. That matters when I am committing client work to a tool, because the question is not just whether it works today but whether it will keep working better in six months. The trajectory here has earned my trust. Review collected by and hosted on G2.com.

What do you dislike about Lovable?

The credit system is the part I have the most complicated relationship with, and it is the place where I would warn anyone going in. The headline price for 100 credits a month sounds reasonable until you hit a debugging loop. When the AI gets stuck on a logic bug, the "Try to fix" cycle can chew through ten or fifteen credits without producing a fix, and I have had single sessions where one stubborn issue ate close to a third of my monthly allowance. The workaround I have settled on is to export the project to GitHub, open the failing code in Cursor or VS Code, fix the bug by hand, and push back. That works, but it is a workaround, not the experience the product promises at the price point.

Credit usage transparency is the related complaint. I cannot tell, before sending a prompt, how many credits it will cost. A small UI tweak might be one credit, a refactor that touches three files might be six, and there is no estimate in the chat before the AI runs. I have learned to write shorter, more atomic prompts to keep the costs predictable, but it took a couple of months of overshooting my budget before I figured out that rhythm. A pre-flight estimate would solve this, and it is the single feature I most want them to ship.

Quality on complex projects degrades in ways that are real and not solvable by prompting harder. Once a project crosses a certain threshold of files and interdependent components, the AI starts forgetting context, reintroducing bugs it already fixed, and proposing refactors that break unrelated parts of the app. My rule now is to treat Lovable as an MVP and prototype tool, not a long-term build environment. When a project gets serious, I export to GitHub and continue the work in a proper IDE. Knowing that boundary in advance saves a lot of frustration, but I do wish the product itself surfaced the limit more clearly instead of letting users discover it the expensive way.

Backend reliability lags the frontend by a noticeable margin. The React layer is consistently good. The Supabase wiring is mostly good. But complex backend logic, things like multi-tenant data isolation, intricate row-level security policies, or workflows that span several edge functions, is where the AI is most likely to hand me something that compiles and runs but does not actually do what I asked. I treat anything in that category as a draft and review the policies and function code line by line before trusting it.

Customer support has been the weakest part of my experience. Response times are uneven, and the answers I have received on credit disputes have been formulaic rather than substantive. The platform itself improves quickly and the changelog moves at a serious pace, so I do not feel ignored as a customer, but if you expect white-glove support at this price tier you will be disappointed.

A credit refund on a documented bug loop should be table stakes, and right now it feels like a favor.

Mobile is the gap that comes up often in my work and that Lovable does not address. The platform builds web apps. If you need a native iOS or Android app, this is not the tool. Responsive web on a phone browser is well handled, but a true mobile app means a different stack and a different conversation with the client. Review collected by and hosted on G2.com.

What problems is Lovable solving and how is that benefiting you?

The core problem it solves is the time and skill cost of getting from an idea to a working web application. Before Lovable, the gap between "I have a concept for an internal tool" and "I can hand a client a clickable, deployed prototype" was at least a couple of days of scaffolding, even with my own boilerplate. Now that gap is hours, and on simpler projects it is closer to an hour. The benefit is not just speed. It is that the cost of testing an idea has dropped to the point where I will build a prototype to settle a debate that I would have argued through a deck.

It has changed how I propose new internal tools to clients. The before-state was sending a written proposal with a Figma mockup and asking the client to imagine the workflow. The after-state is sending them a live URL where they can log in, click through the actual flow, and give feedback against something that behaves like the real product. Approvals that used to take three meetings now take one, because there is nothing left to imagine. The proposal closes faster because the proposal is the product.

Marketing landing pages used to be the worst kind of project to deliver under deadline. The brief lands Friday, the campaign goes live Tuesday, and the gap is filled with someone scrambling through page builders that produce something acceptable but never quite right. Lovable handles the same brief inside an afternoon, with the layout the designer actually mocked up, the form wired to whichever email or CRM the campaign needs, and the page deployed under a custom domain. For agency work and in-house marketing both, this has replaced a stack of single-purpose tools.

The skills gap on smaller projects has also closed in a way I did not expect. I have less technical colleagues who can now build their own internal tools to track what they need to track, without filing a ticket and waiting on engineering. The first one was a hesitant attempt and the result was rough, but the rough version was still useful, and the second iteration was tighter.

The benefit at the team level is that engineering stops being the bottleneck for every small workflow tool, and engineering time goes back to the work that actually needs an engineer.

It consolidated a small stack of tools I was paying for separately. I had a no-code builder for landing pages, a separate tool for forms, a hosted database for any prototype that needed persistence, and a deployment service to put it all together. Lovable covers all of that inside one subscription, and the workflow is a single chat rather than four browser tabs and four sets of credentials. The cost saving is real, but the workflow saving is bigger.

Validating ideas with real users used to be the place where ideas died. The cost of building anything to put in front of people meant most concepts stayed in slide form, and the ones that did get built were the ones I was already committed to. Now I will build a quick version of an idea before I commit, put it in front of three or four users, and either keep going or kill it. That feedback loop is the change in my work that I value most, because it has saved me from finishing projects that should have died in week one.

Code handoff to engineering teams used to be a separate, expensive phase of any project. A designer or product person would build something in a prototyping tool, and an engineer would rebuild it from scratch because the prototype was unusable as a starting point. With Lovable, the prototype is the codebase. It is React with TypeScript, sitting in a Git repo, with tests I can add and components an engineer can extend.

The handoff is a pull request, not a rebuild. That alone has changed how I think about who builds what inside a project, and it has quietly removed an entire category of friction between the people who imagine products and the people who ship them.

There is also a benefit that sits slightly outside the work itself. The cost of learning has dropped. When I want to understand how a piece of modern frontend or backend behavior works, I can ask Lovable to build a small version of it, read the generated code, change it, and watch what happens.

That is a faster way to learn a pattern than reading documentation, and it has kept my own technical skills moving forward in a year where most of my time is spent on coordination rather than implementation. Review collected by and hosted on G2.com.