Skip to content(if available)orjump to list(if available)

Is Lovable getting monetization wrong?

Workaccount2

I'm a non-tech worker in a non-tech industry, let me state two things:

- Software today is written to cover as many use cases with as many features to target as many users a possible.

- End users very often only use a tiny slice of the program's capabilities, but still pay for the entire program.

This creates a situation where the people writing software see it as a monumental undertaking to get good functional programs (it is), and end users see programs as having annoying learning curves with lots of bloat and "unnecessary" features.

LLMs do an excellent job of fixing this for end users because it allows them to easily create a program that does the handful of tasks that they normally need to use MegaSoftware for. And it's tailor made exactly for the use case. And the LLM can tell you exactly how to use it.

I can give a brief example where I used gemini to create a CAD file transposition tool that utilized a simple GUI tailor made for the files my company works with. This allowed us to forgo a (very) expensive CAD software package to work through converting our archive of files. A probably 2M LOC program could be skipped because we only needed 3k LOC functionality.

I really cannot stress enough how often this is the case, and why SWEs see LLMs as weak tools while end users see them as gods.

There will still be a need for huge software packages in the future, but I know I never again have to pay for a huge class of "here is a large solution space that covers your small scope problem" software.

To bring it home, loveable understands this, an sees that the futures has lots of non-tech people "writing" software. Standard IDEs are not the tools your mom will use to make a "Friends and family birthday reminder" app.

98codes

End users rarely pay for the program. Someone in their management chain OKs the purchase, or there's a larger purchase with a cross-charge to the department for the license cost. the problem comes when software needs to meet every whim of the decision maker, when really the users only will ever use 20% at best.

JohnMakin

So true. Some of my favorite enterprise software I use often I could never afford or would never purchase for my own use. I've taken jobs because of this.

bryanrasmussen

I think you may be assuming a certain enterprise size and accompanying workflow, probably would need stats to actually know how much of software is bought in this way however, and if the other way described would open up possible purchases by smaller companies, as was claimed.

jt2190

> I'm a non-tech worker in a non-tech industry…

Certainly you must have enough detailed knowledge of CAD files to validate the output of the transposition tool you had AI create for you. This might not be enough for you to think of yourself as ”technical” but I’d argue that it’s far above the level of “entry level employee using CAD”.

This does also seem to fit the paradigm of “AI is a productivity booster for people who already know how to do x”

qsort

I don't deny that there's utility in what you are describing: if you can make it work for you that's fantastic. However:

- if you can ship software like that given the current state of the technology, you are probably not the average non-tech worker in a non-tech industry. There are people paying exorbitant consulting rates for dashboards in PowerBI. LLMs in mid 2025 are orders of magnitude more operationally complex than anything most people have seen.

- "citizen developers" doing something to scratch their own itches sounds very much like how a professional software project starts. Suddenly the scope grows and you need a nerd to handle it. Then two. Then four. You get the idea. Maybe that won't be the case for your specific needs, but that's how it generally goes.

Weak or strong is a matter of framing, but that's why I see them as tools and not gods.

lbreakjai

I agree with you, and I think the Jevons paradox will eventually manifest itself once again. How many smaller companies are stuck with outdated workflows and tools because they can't afford to pay ten engineers for months on end for something better?

Now those companies may very well be able to afford one engineer and some AI subscription to do the equivalent work.

PaulHoule

Good point. "Build vs buy" is a perennial controversy

https://www.thoughtworks.com/content/dam/thoughtworks/docume...

ebiester

I think there was a consensus over the past decade, but we are now having to adjust our priors. The answer is changing month by month. It also means people are delaying their decision because they are afraid of the wrong solution right now except in the most obvious cases.

x0x0

I don't disagree with the thrust, but I've recently cleaned some of those up.

One example: LLMs aren't smart enough to do things like properly manage zip codes with leading zeros. It was round tripping strings through an integer representation and corrupting them. The users did notice, but did not have the vocabulary/concepts to explain. To them, sometimes zipcodes get corrupted because inscrutable reasons (tm).

chatgpt also authored a bash script that would have blown away a chunk of my drive if any paths had a space in them. :shrug:

asdev

I don't get how this company makes money. Everyone who uses these tools is just building prototypes. They get to 60-70% functionality, but when it comes to actually productionize and launch, 99% of these projects will get abandoned. The churn has to be absurdly high, maybe people are just forgetting to cancel their subscriptions. Or they're just marketing very hard and getting new sign ups/subscriptions, but will crash and burn soon enough.

_fat_santa

> Everyone who uses these tools is just building prototypes.

But also I think that's kinda the point. Like for example we have to do a UI redesign of an app my company is building and our "wireframes" are just v0 projects my PO created in one afternoon.

I think wireframing is where these tools really shine. It's gives you roughly the same ideas as building a wireframe in Figma but it's way less work and you end up with higher fidelity wireframes.Like sure if I were to peek at the code under the hood I'm certain it's close to dogshit but the code doesn't really matter at that stage.

asdev

Any serious company has a brand/design system which Lovable can't leverage well, thus needs designers to use in Figma.

Either way, my point is the customer LTV will be super low for use cases like this.

lbreakjai

I haven't tried with lovable, but gemini studio is fully capable of following a styleguide based on a screenshot, which is probably the crudest and least refined protocol I could think of.

I'm sure there's already integrations somewhere that could allow a designer to specify a bunch of brand colours, to generate a styleguide out of it in plain english, and get a working prototype out of it.

bodge5000

I guess you could argue its just marketing, but if that's the case they're not building "the last software" as they claim. In fact they become entirely reliant on people building more software.

Jun8

I’m using Lovable heavily for PM prototyping and it’s great. I think, if anything, current subscription may be too cheap! They’re probably want to get a huge mass of users now, eg they recently had a free usage weekend.

The comments on the Add Ons are spot on, I think:

“Lovable is creating lots of new software founders who will eventually spend lots of money on vendors. That money will flow, but Lovable currently captures zero of it.”

Having a Lovable App Store sounds like an excellent tool.

bravesoul2

I think you must be the killer use case. As a programmer this is not good enough yet to warrant my time using it for production code (nor are its competitors)

However if I need to prototype for throwaway it would be ok.

These things right now compete with Figma and wire frames. Hopefully they lead ultimately to better UX in software.

hn_throwaway_99

> These things right now compete with Figma and wire frames

I think that is exactly correct. And beyond Figma or wireframes, they can actually be launched to see if they get traction and have product market fit.

Of course, I've seen tons of "throwaway" code that somehow never gets thrown away, and then, somewhat paradoxically, iteration velocity craters as the dev team tries to get a "prototype" to handle real load.

So what I'm saying is that I think things like Lovable are fantastic tools, but I'm quite confident they will be horribly misused and some poor sap will have the job of getting this stuff actually working with edge cases, security issues, scale, etc.

My prediction: this will look basically exactly like Visual Basic in the late 90s. VB was also heralded as "non-expert programmers can make apps just by drag and drop!" I actually think VB was a great product, the problem was most VB programmers were not, so VB apps took on a very negative connotation: like you could tell it was coded by a "VB coder", so you expected it to suck.

janalsncm

I recently used lovable to create the scaffolding for an app. It did a great job, far better than I expected.

However, it also squishes everything into one JS file, making it unwieldy for anything moderately complex. After I fell off the happy path (integrating onnx was basically impossible), I had to spend a fair amount of time reworking it.

I’m probably not the target audience though. And I got the end result faster than I would’ve, and it’s better looking.

mrkramer

Is there really a reason why should I pay for vibe coding apps like this when I can vibe code for free and unlimited with Google's Gemini?

b0a04gl

i see one crazy real leverage: every prototype built here is a frozen snapshot of someone's product thinking in motion. like u can literally watch how ppl prioritize flows, kill features mid-wireframe, choose friction over flexibility. it’s raw cognitive output

if lovable ever starts versioning those moves, storing reasoning behind edits, even lightly, u got a time-series of product intuition across thousands of users. that’s applied decision memory.

there's a window here to become the place where product sense gets archived and replayed.

orbifold

I think what current agent's are missing is taste or the ability to tune taste. So capturing taste across many users might be really valuable.

njovin

...and then PM's can have the same wonderful experiences as engineers: finding the exact commit where a major change was made 6+ months ago by a former employee, with a comment like 'updated behavior' that gives zero insight into what led to the change or why it was made.

logifail

> building the software that can build all other software

All other software?

I'm afraid I stopped believing the author at that point...

clvx

I don't think the idea sticks with me. The final products of these services are never reliable.

Right now, except for some hyperscalers, any similar service has integrated their deployments to some hyperscaler which means any day 2 operations will happen in someone else's computer (supabase, azure/aws, etc). On top of that, you have third party services that you need to integrate and manage their pricing plus auth. That alone is another challenge. Let's not even start with stateful data and migrations which is almost non existent.

The main problem is these tools don't tackle day 2 operations so it will be handled to some developer to make it happen which means exporting your code to some VCS service which I think it's only github. Right there, it's a threat for lovable and others. On top of that, there's not a real feedback loop between manual integration (external dev making it prod ready) and keeping the MVP workflow. Also, there's no real way these services can say "you are free to touch these components without breaking incompatibility with our system, anything else here be dragons".

In other words, You need to own the ecosystem to make more money. Funnel the capabilities to your own ecosystem.

mkagenius

> manual integration (external dev making it prod ready) and keeping the MVP workflow.

Right, the codebase generated by these can get huge, but maintenance can also be aided by AI tools like GitIngest[1], GitPodcast[1] etc. all helping you understand any new codebase easily or someone can query their doubts.

So, I wouldn't strike these kinds of tools yet. AFAIK, v0 already lets you connect github.

1. https://gitingest.com

2. https://gitpodcast.com

exiguus

The marketing is good. Especially on LinkedIn, for non technical people. But I am not convinced. Lovable is a nice Website or App builder. Nothing for professionals, unless they want to build an prototype. Even building MVPs is nearly impossible. It's like v0 from Vercel or anything you can do with other Agents like Claude or Co-Pilot. Lovable is promising a bit to much for my taste.

hackitup7

Perhaps me just stupid and do prompts bad, but I can't make Lovable come up with anything really differentiated as a design. I'm curious if folks have tips on how to use it well as I really love the idea behind it.

Fokamul

Cybersecurity will be booming in 2026, trust me bro :)

I fully support vibe-coding in corporate env., plese bring more :D

mrkramer

Bug bounty programs will blossom like hell!!

donnaoana

Lovable should allow max flexibility to its users, allow them to monetize