Lovable, an application described in a sentence

Lovable, an application described in a sentence

Tools building applications from a natural language description travelled from novelty to something usable for a prototype shown to a client. Lovable is among those that travelled furthest.

You describe what the application should do, and the tool generates a React front end with styling, connects a back end with a database and authentication, and deploys everything at an address you can send to somebody. A first version takes a quarter of an hour.

This text covers what follows in practice: where the tool delivers most, where the boundaries start, and what to do once you reach them.

How it works

Work happens in conversation. You write what should change and the tool modifies the code and shows the result live.

The front end is React with styling built on Tailwind CSS, so the generated code is ordinary code rather than a closed format. That matters when asking what happens once the tool stops sufficing.

The back end rests on a database with authentication and file storage, usually in an integrated variant. Payments connect through an external provider, and deployment goes to the tool's hosting or to your own repository.

Newer versions added an agent mode where the tool reviews code itself, plans a multi step change, and executes it rather than responding to single instructions. On larger changes that is the difference between ten requests and one.

Credits, the thing to understand

Billing rests on credits, and one message consumes a varying number depending on task complexity. That is the most important thing when planning a budget and the commonest source of surprise.

The scale here is smaller than most people assume. The vendor publishes its own examples: recolouring a button costs half a credit, removing a footer nine tenths, adding sign up and login one and two tenths, and generating a landing page with images and five sections just under two. A single message therefore costs on the order of one credit, not dozens. Repetition is what builds the bill: with a mistake and repeated fixing, consumption grows faster than message count suggests.

Three habits reduce that consumption most. The first is a specific description rather than a general one: asking for "a better look" yields a random change and a second attempt, while asking to change heading spacing and colours yields what you meant.

The second is one change at a time. A request covering five things ends with a result where three are good and two must be reverted, meaning more credits.

The third is checking after every change. A bug spotted immediately takes one request to fix; a bug spotted after five more changes takes untangling.

Pricing

The price list is a ladder: on both paid plans you pick a credit tier and the price climbs with it, from a hundred credits up to ten thousand. Worth noting that at the lower tiers Business costs exactly twice what Pro does for the same credit count, since the premium buys organisational features rather than a larger allowance. The billing principle itself stays constant: you pay for credits rather than for time or project count.

A practical way to estimate: build one small project on the free or lowest plan and check how many credits adding one complete feature consumed. Multiplying that by your planned scope gives an estimate closer to the truth than any plan description.

One term is worth holding in mind while planning: credits expire. Daily grants on the free plan do not carry into the next day, monthly credits lapse two months after they are issued, and separately purchased ones after a year. Stockpiling for the future therefore makes no sense beyond top ups.

Where the boundaries sit

A tool of this kind holds an advantage at the start and loses it as a project grows. It helps to know where that shift happens.

For a prototype, a marketing page, an internal tool, and a product's first version it performs very well. The scope is small then, requirements simple, and speed of creation matters more than code structure.

The boundary appears at three things. The first is complex business logic: rules depending on many conditions, calculations requiring precision, multi stage processes. Describing that in a sentence is harder than writing the code.

The second is size. An application with forty screens stops fitting in context, so a change in one place can break another and the tool will not notice.

The third is nonfunctional requirements: performance under traffic, screen reader accessibility, regulatory compliance. Those must be asked for explicitly, and even then the result needs checking.

The exit to your own code

That is the most important property when assessing risk and worth knowing before starting a project.

Code exports to your own repository and you work on it normally. It is not a closed format but a React project you can run locally and deploy anywhere.

That changes the nature of the decision to use the tool. The risk lies not in getting stuck but in how much work taking over code nobody on the team wrote will cost.

Practical advice: export the code and review it before the project grows. Structure, naming, and state handling are easier to fix at ten screens than at forty.

The first review takes a few minutes and comes down to three questions: does it build at all outside the tool, how many dependencies are there, and is anything sensitive sitting in the code.

git clone git@github.com:company/project.git && cd project
npm ci && npm run build
npx depcheck
grep -rInE "(sk|pk)_(live|test)_[A-Za-z0-9]{10,}" src/

Run that last command even when you are sure there are no keys in the code. The check costs a second, and skipping it has already cost many people considerably more.

Work with a connected repository from the start too, rather than exporting only at the end. Every change then has history you can return to, and code review happens continuously instead of once under pressure.

How to write requests that work

Output quality depends on the description more than on anything else, and the gap between a good and a poor description is a gap in credits spent.

The first rule concerns reference. A request pointing at an existing element beats an abstract description: "make an orders list like the customers list, with number, date, and amount columns" yields something matching the rest of the application, while "add an orders list" yields something new that looks different.

The second concerns scope. One request covers one screen or one feature. A request for a whole module ends with a result where half needs fixing, and fixing costs more than doing it in three steps.

The third concerns edge states. The model builds the path where everything works, so an empty list, a save failure, and text longer than allowed for need their own request. Name them up front rather than discovering them during a demo.

The fourth concerns data. Describing the data structure before the interface exists saves rebuilds. A model that knows an order has line items, a customer, and a status builds different screens from one that learns it at step three.

The fifth concerns fixes. Rather than asking generally for something to be fixed, say exactly what is wrong and what you expect.

Weak:   fix the order form

Better: on the order screen the save button does not disable after a
        click, so a quick double click creates two orders. Disable the
        button while the request is in flight and show a loading
        indicator. Leave the rest of the screen unchanged.

The sentence about what not to touch matters as much here as the description of the fix. Without it the model often rebuilds the screen layout along the way, and you pay credits for a change you did not ask for.

Security of generated code

This area gets discussed least and matters most on a product accepting user data.

Generated code runs, and that does not mean it is safe. Three things deserve checking before releasing anything publicly, however good the preview looks.

The first is data access rules. A database with authentication protects data only when the rules are set correctly. Default configuration is sometimes open, so a query from the browser can read other users' rows.

With a Supabase backend, which these tools pick most often, the check comes down to two queries.

select tablename, rowsecurity
from pg_tables
where schemaname = 'public';

select tablename, policyname, cmd
from pg_policies
where schemaname = 'public';

A table with row level security disabled and a table with it enabled but carrying no policy at all are two different problems with the same effect. In the first case everything is visible, in the second nothing is, and the application stops working in a way nobody can explain.

The second is permission checks on the server side. Hiding a button in the interface is not a safeguard, and generated code sometimes stops at that first step.

The third is keys. A key to an external service placed in code running in the browser is visible to anybody opening developer tools.

Checking takes a moment and requires no code reading: just look through the finished output bundle, since that is exactly what reaches the browser.

npm run build
grep -rInoE "(sk|rk)_(live|test)_[A-Za-z0-9]+" dist/ | head

If anything turns up, the key itself has to be rotated rather than merely removed from the code. The bundle may already have reached browsers, and a value once sent out stops being secret regardless of what you do in the repository afterwards.

Practical advice: before releasing a product taking payments or personal data, ask somebody who can program to review those three things. That is an hour's work guarding against a problem that takes weeks to repair.

Lovable against the alternatives

Note that the first three rows and the fourth answer different questions. Generative tools answer how quickly an idea can be checked. Working in an editor with an assistant answers how to grow a project meant to last.

A common and sensible arrangement combines both. A first version comes from a generative tool, and once the idea proves out, the code moves to a repository and further work happens in an editor. That path uses both approaches' advantages rather than choosing one forever.

Recognising the moment of transition early pays off. There are several signals: further requests break things that used to work, fixes consume more credits than new features, and you describe what you do not want more often than what you do. Each of them alone can be chance; all of them together mean the project outgrew the tool.

The transition need not be all or nothing. Some teams keep the tool for prototyping new screens and move them into the repository once the shape is agreed, treating it as a sketchpad rather than a production environment.

Common mistakes

The first is general requests. A description like "make it nicer" yields a random change and burns credits on a result you did not want.

The second is several changes in one message. The result then mixes good and bad, and reverting part of it takes further attempts.

The third is not previewing after every change. A bug spotted five steps later costs more than one spotted immediately, since you must work out which step introduced it.

The fourth is building a product handling payments and personal data on this tool without a code review by somebody who can program. Generated code runs, and that does not mean it is safe.

The fifth is deferring the export to a repository. Code without change history and without review grows, and taking it over after three months is harder than after three weeks.

The sixth is assuming the tool replaces knowing the basics. Without understanding what a database is, what authentication does, and where errors come from, work stops at the first problem that cannot be described in a sentence.

FAQ

What does Lovable cost?

The free plan gives a few credits daily for trying the tool, and paid plans start around twenty dollars a month and rise with the credit allowance. Tiers change, so check the current price list at source before deciding.

What are credits?

A billing unit consumed on every message, in an amount depending on task complexity. A simple appearance change costs a fraction of a credit, adding sign in slightly over one, and generating a whole landing page just under two. The cost of each message shows in the interface.

Can the code be exported?

Yes, the project is an ordinary React application you can run locally and deploy anywhere. Connect a repository from the start so changes carry history and code review happens continuously.

When does the tool stop sufficing?

At complex business logic, at an application with dozens of screens, and at requirements about performance or accessibility. The sensible route then moves the code into a repository and continues in an editor with an assistant.

Does it replace learning to program?

No. The tool shortens the path from idea to a working version, and understanding what was produced remains necessary, particularly on bugs and on questions about security. Without that knowledge, work stops at the first problem requiring diagnosis.

Documentation sits on the project site, and a plan comparison appears in a pricing guide.