[HN Gopher] Is Lovable getting monetization wrong?
       ___________________________________________________________________
        
       Is Lovable getting monetization wrong?
        
       Author : FinnLobsien
       Score  : 93 points
       Date   : 2025-06-25 14:05 UTC (8 hours ago)
        
 (HTM) web link (getlago.substack.com)
 (TXT) w3m dump (getlago.substack.com)
        
       | pwatsonwailes wrote:
       | I'm pretty sure the person who wrote this has never run pricing
       | research for a brand. Short answer, they can ignore Gabor-Granger
       | because their cost base is so low compared to their revenue, so
       | they'd be looking at Van Westendorp's Price Sensitivity Meter to
       | set a benchmark for where the pricing probably lands, and a
       | conjoint study to understand the value of different elements for
       | segmenting different versions of the product at different price
       | levels.
       | 
       | Obviously positioning, who they're positioning against, how they
       | communicate that, the level to which they're known amongst the
       | market etc all feed in to this, but that'd be a decent starter
       | for ten.
       | 
       | This is an overly simplistic version of where to go with pricing
       | for a brand like this, but that's where I'd begin with creating
       | pricing for them.
        
         | echelon wrote:
         | I'm an engineer. Where do I begin learning these things without
         | taking an MBA?
        
           | Jun8 wrote:
           | https://m.youtube.com/watch?v=iuRbDBAqyFY&t=9s&pp=2AEJkAIB
           | 
           | https://www.qualtrics.com/marketplace/vanwesterndorp-
           | pricing...
           | 
           | https://www.amazon.com/Confessions-Pricing-Man-Affects-
           | Every...
           | 
           | https://www.amazon.com/Strategy-Tactics-Pricing-Growing-
           | Prof...
        
             | echelon wrote:
             | Thank you so much!
        
         | neolefty wrote:
         | Yup. Like comparing pricing of cars to pricing of horses.
         | Lovable is competing with future platforms, not present ones.
        
           | bravesoul2 wrote:
           | This is interesting to pull apart if anyone wants to add more
           | id love to hear.
           | 
           | Right now Lovable has competition in the vibe coding arena.
           | Like Replit for example. I found Replit to be better in my
           | testing.
           | 
           | I think there is an interesting curve where software is
           | generally worthless (see Github!) but software plus
           | marketing/sales etc. is valuable. But if you have any kind of
           | scale that software needs to be robust and AI can't do that
           | yet.
           | 
           | So there is a weird evolving Venn diagram where the final app
           | industry fits in. If one player can take it yeah they'll be
           | the next Google but that's a big IF and a big WHO.
        
         | pluto_modadic wrote:
         | what's funny is they're a bill metering company.
        
         | mike_hearn wrote:
         | How do you know what their cost base is? I don't quite
         | understand how you'd be evaluating that. Their cost base is
         | largely driven by the LLM and cloud companies. The $25/month
         | pricing feels chosen to be similar to other unrelated SaaS
         | businesses more than something based on a serious pricing
         | analysis.
         | 
         | And the article confirms that, saying they made up a starting
         | price and then immediately lost money due to (doh) selling a
         | product where your costs scale by usage for an unlimited flat
         | rate, which is surely one of the most basic pricing issues out
         | there. And not just for LLMs: they host the apps too, putting
         | them on the hook for hosting costs. They're using a ton of very
         | expensive PaaS services like Supabase to do that too.
         | 
         | Then they have the free tier. Such services often have massive
         | free tier costs; if their userbase is made up of a lot of
         | people just trying stuff out quickly before exporting it to
         | GitHub to continue, that problem will be worse. According to
         | their blog, they have 30,000+ paying customers but there are
         | 25,000 new apps created _per day_ with 1.2M apps overall. So,
         | clearly, almost all apps are being created by free users.
         | 
         | Don't get me wrong, maybe they're printing money like there's
         | no tomorrow, or maybe they will soon. But it feels like the
         | sort of business that's probably burning VC money to buy market
         | share. If their cost base _is_ good then they feel very
         | vulnerable to an OpenAI or AWS releasing something tomorrow
         | that takes away a big chunk of the business, seeing as that 's
         | where the bulk of the value lies. Oracle already has something
         | quite similar launched in APEX.
        
       | logifail wrote:
       | > building the software that can build all other software
       | 
       |  _All_ other software?
       | 
       | I'm afraid I stopped believing the author at that point...
        
       | Jun8 wrote:
       | 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 wrote:
         | 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 wrote:
           | > 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.
        
       | clvx wrote:
       | 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 wrote:
         | > 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
        
       | b0a04gl wrote:
       | 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.
        
         | njovin wrote:
         | ...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.
        
         | orbifold wrote:
         | 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.
        
       | hackitup7 wrote:
       | 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.
        
       | asdev wrote:
       | 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 wrote:
         | > 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 wrote:
           | 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 wrote:
             | 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.
        
               | marcosdumay wrote:
               | A design system is not "following a styleguide based on a
               | screenshot". A design system is an ontology of UI
               | elements that your software has to adhere to, with
               | several rules about how those elements are or aren't
               | allowed to interact.
               | 
               | Following a styleguide will make your software break as
               | soon as the design system gets updated.
        
           | bodge5000 wrote:
           | 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.
        
         | lubujackson wrote:
         | I noticed in the example product the person was bragging they
         | made "$1.6k in 5 weeks" but looking at the screenshot they were
         | selling "lifetime access" built on this product they pay $25 a
         | month for. I think there is going to be a reckoning for all
         | these fly-by-night SaaSlings and the poor people who start to
         | rely on them.
        
       | Fokamul wrote:
       | Cybersecurity will be booming in 2026, trust me bro :)
       | 
       | I fully support vibe-coding in corporate env., plese bring more
       | :D
        
         | mrkramer wrote:
         | Bug bounty programs will blossom like hell!!
        
           | _pdp_ wrote:
           | We have AI tools working on those as well. ;)
        
       | deadbabe wrote:
       | These apps will look dated in a few years, don't waste your time.
       | You're just having fun playing around making old shit that could
       | have made you a lot of money 10 years ago but is now just a
       | weekend project. That's the way things go in tech. Starry-eyed
       | dreamers will let their imagination run wild, but they're the
       | laggards, the industry is already thinking ahead.
       | 
       | The next generation of apps isn't going to look like the previous
       | gen. No beautiful UIs and fancy CSS. No UI at all.
       | 
       | Instead, everyone will have some kind of platform like Cursor,
       | but instead of just coding, it's for _everything_.
       | 
       | Subscribing to new services for your AI to use will be the
       | equivalent of downloading apps from an AppStore to your phone.
       | 
       | Then you can just say things like "fuck this person! AI, give me
       | an OSINT profile of this Redditor!" and since your AI has the
       | osint app it compiles the info instantly and says "here, damn".
       | No need to open an app, just straight info into your brain as
       | quickly as possible.
       | 
       | AI has clearly made us tired of googling endlessly for info on
       | random websites, so why are we still opening up apps to do
       | various tasks? Because we want to see pretty interfaces? Get
       | real. It's time for the UNIX philosophy to go mainstream. Start
       | thinking of how your product can minimize time to satisfaction,
       | graphical interfaces get in the way of satisfaction.
       | 
       | The only problem is we currently don't have a single unifying
       | platform like an iPhone or something to consolidate a user base,
       | but it will come. Start planning for that day so you can launch
       | new services on day 1. It will be a gold rush.
       | 
       | And in the end, a lot of people will find they will struggle with
       | coming up with good AI app ideas, because 80% of their idea was
       | just putting a pretty interface in front of something complex.
       | That's how you know it was mostly a bad idea.
        
         | lbreakjai wrote:
         | Would you need a new platform, or just a screen and a
         | microphone?
        
         | lubujackson wrote:
         | Love this concept - LLMs as the new "API layer" to everything.
         | Don't design a frontend because the user can generate one on
         | the fly or use their own styling or pick a common "theme".
        
           | deadbabe wrote:
           | Exactly, bring your own front end. No more worrying about
           | "user experience"
        
         | cadamsdotcom wrote:
         | With that mindset you'd have skipped getting a PC in the 90s
         | because the Internet in your pocket is gonna happen any day
         | now.
         | 
         | For example let's say the agent you describe can relieve people
         | of manual data extraction from websites. Such an agent would be
         | sheer utter magic for a friend of mine. Part of their role
         | involves logging in to get data on employees from 4-5 different
         | systems, compiling a spreadsheet of the data, turning the
         | spreadsheet into a report, and sending it to internal folks.
         | It'd be great to have an agentic tool that can drive the data
         | extraction piece and automate their entire process with just a
         | prompt - but today's tech works just fine! A Playwright script,
         | some carefully stored credentials, and a workflow automation
         | are enough to get the job done - even if they require constant
         | tweaking and monitoring.
         | 
         | Today's tech is never the ideal version you can imagine, but it
         | can still be used to solve important problems. Better to enjoy
         | what is happening now even if you know it's temporary.
        
       | exiguus wrote:
       | 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.
        
       | Workaccount2 wrote:
       | 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 wrote:
         | 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.
        
           | bryanrasmussen wrote:
           | 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.
        
           | JohnMakin wrote:
           | 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.
        
             | Munksgaard wrote:
             | IDA?
        
         | lbreakjai wrote:
         | 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 wrote:
         | Good point. "Build vs buy" is a perennial controversy
         | 
         | https://www.thoughtworks.com/content/dam/thoughtworks/docume...
        
           | ebiester wrote:
           | 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 wrote:
         | 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:
        
           | lubujackson wrote:
           | Fun thing I noticed is converting a CSV to XLSX in Excel also
           | drops leading 0s from zip codes...
        
         | jt2190 wrote:
         | > 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 wrote:
         | 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 wrote:
       | I work for a very small startup. Our CTO heavily uses lovable for
       | our internal tools. Think dashboards, user management ... A
       | somewhat standard UI over CRUD operations.
       | 
       | In previous roles, we either used some SaaS platform and would
       | end up designing features based on the limitations of the tools,
       | or we'd spin up a team to roll our own tailored solution. (or,
       | God forbid, use Oracle and pay consultants a small fortune to do
       | it for us).
       | 
       | With lovable, our CTO can validate assumptions and iterate on
       | their own. Even if the code was absolutely garbage and we deleted
       | all of it, this alone saves us a ton of man hours per feature.
       | There's an entire lossy communication loop that's been removed.
       | 
       | Now, the code is only ok. We generate API clients from openapi
       | definitions but it will struggle to properly orchestrate them. It
       | will absolutely not have sane defaults anywhere, and will abuse
       | the "any" type.
       | 
       | You still need a human in the loop, but my back of the napkin
       | calculation is we'd have to hire two full time developers to do
       | the work it's been doing for us.
        
         | htrp wrote:
         | Why does your CTO not use cursor or whatever other code IDE
         | tools to build on your own standard internal stack?
         | 
         | At least that would allow them to handoff to other members of
         | the team.
        
           | lbreakjai wrote:
           | Lovable operates at a higher abstraction level. You describe
           | what you want, the UI magically updates, you never have to
           | see the code.
           | 
           | Changes made by lovable aren't anything special. They live in
           | their own branch, and get periodically merged to master, so
           | you can carry on working on it as if it was any other
           | project.
        
       | donnaoana wrote:
       | Lovable should be in the money flow, allow their users to
       | monetize
        
       | donnaoana wrote:
       | Lovable should allow max flexibility to its users, allow them to
       | monetize
        
       | janalsncm wrote:
       | 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 wrote:
       | 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?
        
       | esher wrote:
       | Good product placement of Lago :)
        
       | chaosprint wrote:
       | just have a question, for a young company like this, isn't mrr
       | better than arr? or do they have that many yearly subscription?
       | cuz u always subscribe and cancel different providers
        
       | _pdp_ wrote:
       | The kind of things I see mostly produced by these tools are
       | landing pages, example dashboards and simple utilities like
       | calculators and other simple stuff. There is certainly a space
       | for these but nothing ground breaking that was not possible
       | before with other beginner-friendly tools. The only difference is
       | now that there is more freedom because LLMs can do more with less
       | constraints.
       | 
       | I wonder what will happen after the honeymoon is over - after
       | people realise that software development is not about writing new
       | exciting code but maintaining things that should have been
       | replaced years ago that are now too important because other
       | people depend on it.
       | 
       | > I remember we were building a micro-app like that and it took
       | at least a month, now it takes 3 minutes.
       | 
       | ...please, statements like this have the power to invalidate the
       | rest of the commentary. in 3 minutes you can complete a few
       | prompts not nearly enough to write a piece of software the
       | allegedly takes 3 months to do.
        
       ___________________________________________________________________
       (page generated 2025-06-25 23:00 UTC)