What are you really buying when you buy Lovable?

Lovable is the first product I have chosen for a new experiment.

The experiment is simple: take apps and systems presented as game changers, work backwards from the promised outcome, and ask how much a capable person with a serious AI subscription could already reproduce independently.

The purpose is not to ridicule the people building them.

It is to understand what the product really is.

That distinction matters because AI has changed the economics of software creation. The ability to build an application is becoming widely available. The ability to build a durable company is not.

Why start with Lovable?

Lovable is a strong first case precisely because it is not an obvious, thin wrapper around a single prompt.

Its promise is much larger.

Describe an idea in ordinary language and Lovable can generate the interface, application logic, database structure, authentication and deployment. Its own documentation describes a path from a first prompt to a live, shareable application in around ten minutes of hands-on time for a simple project.

It also provides visual editing, version history, hosting, a managed backend and GitHub synchronisation. The generated code belongs to the user and can be moved elsewhere.

That makes Lovable a fair test.

If we began with a weak product, proving that ChatGPT could reproduce it would tell us very little. Lovable forces us to separate two different questions:

1. Can a paying AI user recreate the result? 2. Can the user recreate the complete experience of producing that result?

Those are not the same thing.

Working backwards from the outcome

A user does not really buy React components, database tables or deployment files.

The user buys movement from an idea to a working application.

That movement contains several jobs:

clarify what should be built
translate the idea into requirements
create a usable interface
generate application logic
establish authentication and data storage
test whether the important flows work
publish the application
make changes without breaking everything
maintain and improve it over time

Lovable puts these jobs inside one guided environment.

But almost every individual capability is now available elsewhere.

A paid ChatGPT user can develop the idea and specification conversationally. Codex can create and change the code, work with GitHub, run checks and deploy through services such as Vercel. ChatGPT Sites can create, host and refine websites and web applications directly from a prompt, including experiences with persistent data and sign-in. Supabase can provide the database, authentication, storage and backend services.

The ingredients are no longer scarce.

The integration is.

My current hypothesis

We have not yet run a controlled build in Lovable and ChatGPT side by side. We already have substantial development work in progress for our own and our clients’ projects, so the first analysis is deliberately theoretical.

The percentages below are therefore hypotheses to be tested, not findings disguised as precision.

For a simple website or prototype, I expect a capable paying ChatGPT user to reproduce approximately 85–100 per cent of the practical outcome.

For a conventional internal application with authentication, forms, tables, search, filters and persistent data, I expect the user to reproduce approximately 70–90 per cent of the outcome, although setup and verification may require more steps.

For Lovable’s complete integrated experience — moving from a blank page to a deployed full-stack application inside one beginner-friendly interface — I expect the reproducibility to be closer to 50–75 per cent.

The gap is important.

It is not primarily a gap in what can ultimately be built.

It is a gap in friction.

The product is the distance removed

This changes how I think about Lovable.

Lovable’s product is not simply AI-generated code.

Its product is the distance it removes between intention and execution.

It removes the need to decide which framework to use, where the database should live, how authentication should be connected, how the application should be hosted and how changes should move from an instruction into production.

A technically capable user working with ChatGPT may be able to reach the same destination. But the journey can involve several tools, accounts, permissions, choices and moments where something fails.

Lovable compresses that journey.

That compression can be worth paying for even when none of the underlying capabilities is unique.

This is the same reason people buy prepared meals even though they own a kitchen, use an accountant despite having access to the tax rules, or pay for project software when spreadsheets could technically reproduce most of the functions.

Reproducible does not mean worthless.

It means the source of value must be described correctly.

What this means for users

If someone already pays for a capable general AI system, the first question before buying another application should be:

Do I need this product, or do I need a well-designed workflow using tools I already have?

For a simple website, dashboard or prototype, the answer may increasingly be the latter.

For a non-technical user who values speed, visual control and one place to manage the entire process, Lovable may still be the better decision. A modest subscription can be cheaper than the time and uncertainty involved in assembling the same result across several services.

The relevant comparison is therefore not subscription price versus zero.

It is:

Subscription price versus the time, knowledge, coordination and risk the product removes.

What this means for founders

The more serious lesson concerns people building new AI products.

It is no longer enough to demonstrate that an application can be built.

It is no longer enough to show an impressive result from a prompt.

And it is certainly not enough to assume that development creates a barrier competitors or customers cannot cross.

If a general AI system can reproduce most of the outcome, defensibility must come from somewhere else:

a substantially better workflow
proprietary or compounding data
deep integration into the customer’s operations
distribution and trusted relationships
reliability and accountability
network effects
exceptional user experience
a learning system that improves with real use
the ability to remove complexity consistently, not merely once

Lovable appears stronger than many narrow AI applications because it is building around the whole production journey rather than one isolated output.

But it is also exposed to the same strategic pressure.

The general AI systems beneath and beside it are expanding. What requires a specialist builder today may become a standard capability inside the subscription people already have tomorrow.

The product must therefore keep moving further up the value chain.

What changed

I began with the assumption that reverse-engineering an AI product meant reconstructing its technical functions.

Lovable makes that definition too narrow.

The more useful analysis is to reconstruct the value chain:

What outcome is promised?
Which parts are technically difficult?
Which parts are merely inconvenient?
Which parts can a general AI subscription already perform?
Which parts remain valuable because they reduce coordination, risk or cognitive effort?
What becomes the moat when code generation itself is abundant?

That is a better test than asking whether we can produce something that looks similar.

What I think matters

We should stop treating buildability as proof of value.

A product can be easy to reproduce and still be worth buying.

A product can also be impressive to build and still be a poor company.

The commercial question is not whether the technology works. It is whether the product removes enough cost, uncertainty or effort to remain preferable when the customer’s existing AI can perform more of the work every month.

Lovable’s strongest defence may not be better code generation.

It may be that users do not want code generation at all.

They want the shortest dependable path from an idea to something that works.

What remains uncertain

The central hypothesis still needs to be tested.

When our current development priorities allow it, the fair experiment is to give Lovable and ChatGPT the same assignment and measure:

time to the first usable result
number of instructions and corrections
manual work required
functional completeness
visual quality
authentication and data security
deployment reliability
portability
ongoing maintenance effort
total cost

Until that comparison is complete, I will not claim that ChatGPT replaces Lovable.

The theoretical conclusion is narrower:

A paying ChatGPT user can probably reproduce most ordinary outcomes Lovable creates. What the user may not reproduce as easily is the simplicity of getting there.

That may be the real product.