Lovable builds the demo, and the demo was always the easy part

The prototype opened at 9:40 in a conference room rented by the hour at a client's office park, and by 9:47 the renewal was decided. It wasn't a deck. It was a clickable thing, a fake version of the client's own workflow with buttons that behaved, and the client's operations lead leaned forward and said the sentence that closes deals in that world: this is exactly what we mean. The sales engineer had built it in about a week. I remember watching the client's CFO, who had objected to the renewal for a month, watch the screen, and I remember that he never asked how the prototype worked, only whether it could look like that on their data. It could not, yet. That was the arrangement. The prototype implied a product, the product took eleven months of engineering to exist, and the eleven months were never shown to anyone. They were spent by people who weren't in the room, on problems the demo had carefully cropped out. The renewal was won in seven minutes. It was kept over eleven months.

Lovable is a builder where you describe software in a prompt and it produces a working version in front of you, and since its late 2024 rebrand out of a project called GPT Engineer it has become the fastest-growing thing in its category: annualized revenue passed $600 million in September 2026 and the valuation ran from $1.8 billion in July 2025 to $13.3 billion in August 2026, per TechCrunch, on the strength of people building more first drafts than anyone expected. What the product sells, functionally, is the sales engineer's week. A product manager who couldn't code, which was me for two years, can now build the clickable thing himself, against his own data, in an afternoon, and walk it into the meeting. I've done versions of this and I'll defend the practice before this essay ends. But the distance between the demo and the product isn't closed by a tool that produces demos faster. The distance has been moved: it used to sit between the sales engineer and the room, and now it sits between whoever built the thing and the stranger who arrives later. That stranger is the part the prototype never showed, and Lovable builds the prototype. The tool makes the easy part easier, and then prices the gap between easy and real by the message.

Credits price the almost-right

The plans are cheap and the pricing is a meter. Free gets five credits a day, capped near thirty a month. Pro starts at $25 a month for a hundred credits. Business starts at $50 a month for the same hundred, where each credit simply costs twice as much, and topping up extra credits runs about twenty percent above the plan rate. Those figures come from the vendor's own documentation, updated at the start of October 2026. Credits are spent when the model builds or edits, and in the default mode the cost of a message varies with the task's complexity, which means the meter's dial is invisible from inside the prompt box. Consider the incentive. The vendor's best revenue does not come from the person whose first draft worked. It comes from the person whose draft is almost right: close enough to keep going, far enough to keep paying. Every iteration is a message, and iteration is the workflow the product itself recommends. Meanwhile the Business tier exists to sell single sign-on and a data-training opt-out to the companies that realized what they were holding, which doubles the base price for an identical hundred credits. The security of the thing you shipped is priced as a feature of the plan. That line item is the whole industry in miniature.

What the demo doesn't render

In May 2025, Reed Albergotti reported in Semafor (the piece is here) that a security scan of 1,645 apps built on Lovable found 170 exposing user data to anyone who knew the address, including password-reset flows and, in some cases, other customers' records. Semafor called the company a sitting duck for hackers. Lovable disputed the framing and shipped fixes, and the underlying flaw received a CVE record the same week. I'm not going to adjudicate the scan's exact rate, because the number matters less than the shape: authorization, permissions, what a stranger is allowed to do once inside. None of that is visible in a prompt window. None of it is rendered by a demo. All of it is what the eleven months used to be for. The prototype at the client meeting cropped out the stranger, and that was acceptable, because the prototype was not the product. Now the prototype can be the product, and the stranger arrives anyway, without waiting for the engineering. The most sobering part of the 170 apps is who built them: people like the client's operations lead, who meant well and shipped what they could see. What they couldn't see was the part that only exists when somebody hostile logs in.

The demo was always the specification

Now the honest case for Lovable, which is better than its marketing. The demo is not a deception. It's the specification, in the only language most stakeholders can read, and a product manager who can show rather than describe wastes far less engineering time than one who writes tickets about a feeling. Most of what gets built this way is internal: dashboards, workflow tools, calculators with an audience of forty, software that never needs to survive the open internet because the open internet has no reason to find it. A preprint by Li and colleagues last September, built on interviews with product teams using AI-assisted building, describes exactly this: prototyping speed changed which ideas reached a meeting at all, because an idea with a body gets discussed differently than an idea in a paragraph. It's a preprint, not a peer-reviewed finding, so hold it loosely, but it matches what I've watched happen. I work alone now, with no engineers, and I am precisely the buyer this product was built for, which means my incentives here are the opposite of clean. I like the tool. I have drafts in it. For the person in the seat, a cheap almost-real thing that answers a real question by Thursday is not worthless because its error handling is thin, and the people who will tell you it is have never had to wait eleven months for an internal calculator. Both things are true, and they are usually true of the same app.

The verdict depends on what you build and who can reach it. If the thing stays internal, build the prototype, ship it, and stop reading security essays. If strangers can sign up, the demo is not the product, and the eleven months are still owed, now payable to someone with the word security in their title instead of engineer. The variable worth watching is not how many apps get built. It's who remains to build the eleven months. Somewhere a client signed a renewal in seven minutes over a prototype, and a team spent eleven months making the prototype true, and the client was never really the customer the prototype was built for. The demo was built for the room. The stranger is never in the room.