Lovable: the prettiest first draft, and a metered second draft

The leader

How to choose an AI app builder, in the order the decisions actually matter

An AI app builder takes a description in plain English and produces working software. Two years ago the interesting question was whether that was possible. It is now settled: every tool in this index will hand you a running application from a paragraph of prose, and among the leaders the raw difference in generation quality has narrowed to the point where it should not decide your purchase. The differences that remain are about what happens on day thirty, and those differences are large.

We rate thirty-seven builders out of five stars across ten weighted axes. The weighting is published, adds up to one hundred, and is the same for every tool. But a single number cannot tell you whether a product fits your situation, so here is the order we recommend thinking, based on running six fixed briefs through every tool in the index three times each.

Start by deciding whether you are building an app or a website

This sounds condescending and it is the most expensive mistake we see. Four of the tools we rate are, functionally, site builders with an assistant attached. They are genuinely excellent at marketing pages and hopeless at anything with accounts and relational records. If your project has users who log in and see different data from one another, you need a full-stack builder, and retrofitting accounts onto a site tool means starting again. If it does not, you will get a better result and pay a third of the price with a design-led tool. Our guide for SEO websites and our guide for a SaaS MVP split along exactly this line.

Then work out who fixes it when it breaks

Every builder breaks. What differs is what you are looking at when it does. On the developer-first platforms you get a stack trace and a shell. On the batteries-included platforms you get a chat window and a friendly apology. Neither is better in the abstract, and this is where an overall star rating misleads most: our non-technical testers finished projects on tools that score mid-table and abandoned projects on the tool that scores near the top, because a stack trace is a wall if you cannot read code. Be honest about which side of that line your team is on before you look at a single feature list.

Price the failed attempts, not the plan

Around a third of the tools here meter usage in credits or tokens. The advertised monthly price tells you what a good month costs. Failed attempts consume the same credits as successful ones, and the tools that recover worst burn most on their worst days. Our data editor tracked real spend on every test build: on a good run a medium feature cost between four and eleven euros of usage, and on a bad run the same feature cost between nine and thirty-eight. A useful rule is to double the plan price for any month in which you are actively building. If that number is unacceptable, restrict your shortlist to the two flat-priced platforms, and read our analysis of credit pricing.

Ask what happens if you want to leave

Three tools in this index offer no code export at all. For a campaign microsite that is fine. For the process your business runs on it is a migration cost you have not budgeted for. The right question is not whether you can export but whether the export would run: a zip file that needs a proprietary runtime is not an exit. We tried moving four finished applications onto our own server and only two survived the trip.

Check whether the output can be found

If organic search or an answer engine is your growth channel, this is not a footnote. We weight SEO and GEO at thirteen percent because an application nobody can find is a hobby. The tests are dull and decisive: does the page render its main content on the server, is it legible with JavaScript disabled, can you set a unique title and a canonical URL per route, is there a real sitemap. Three builders we tested produced pages whose main content was entirely absent from the initial HTML response, and two offered no way to set a canonical URL at all.

Only then look at the agent

Agent quality matters most in the middle of a long project, not at the start. Every tool is impressive on prompt one. The question is what happens on prompt forty: does it still know what the application is, does it remember the decision you made in week one, and when it is wrong does it fail loudly or quietly. Quiet failure is the worst property an agent can have, because it converts saved building time into wasted review time, and the tool with the most impressive planning in our testing also had the highest rate of confidently reporting finished work that did not function.

What we would actually do

If you have engineers and an API, generate the front end and keep your backend. If you have engineers and no backend, pick the tool with a real runtime behind it. If you have no engineers and the app is internal, pick the most forgiving platform and accept the lock-in as a deliberate decision. If you have no engineers and the app faces customers, pick the best visual output and budget for a contractor for the last twenty percent, because there will be a last twenty percent. The table below is ordered by our overall rating; the column that should decide your purchase is best for.