Lovable has carried that name for only about three months. It began as GPT Engineer, an open-source project based in Stockholm, and adopted its new name in December. It is currently the tool most frequently featured in screenshots in our feeds, usually with a caption such as "built this in twenty minutes."
The promise is simple: you type what you want, and a web app appears on the right side of the screen. If you change your mind, you type a new instruction.
For the most part, the tool delivers on that promise. This is precisely why it is useful to be clear about its limits.
What does Lovable do well?
The first hour with Lovable is striking for anyone trained to build sites the traditional way. Describe a landing page for a café and you obtain a landing page: a sound layout, sensible spacing, a menu section and a contact form that displays properly on a phone. Request a darker header and it changes. Request a gallery and one is added.
Underneath, it writes real code: a modern JavaScript front end built with React. This matters more than is often assumed. It is not a closed page builder in which your site remains permanently inside someone else's database. The code exists, you can take it with you, and a developer can open it later and understand how it works.
For certain types of projects, it is very difficult to match:
- a one-page site for a new business that needs to exist online this week
- a clickable prototype to show a partner, a banker or a grant officer
- an internal tool, like a simple form that sends staff requests to one inbox
- a test of an idea before you spend real money on it
The last of these may be the most valuable use. Discovering that an idea does not hold up costs very little when the version being discarded took only an evening.
When is a developer still needed?
The first version is produced quickly. The second version is where careful planning becomes necessary.
As soon as an app needs to store information, such as bookings, user accounts or orders, it requires a database. Lovable connects to Supabase for this purpose and creates the tables for you. What it will not necessarily do on its own is ensure that the right people can see the right rows and that no one else can. Supabase provides the tools for this, row-level security, but someone has to define the rules and then verify them. If no one on the project is aware of this feature, it is very easy to launch an app in which customer data can be read by anyone who explores it a little. An automated scan can detect part of the problem, but it cannot know your business rules. That knowledge has to come from you.
A second concern, from an SEO perspective, is how the pages are built. A Lovable site is a single-page app: the browser receives a nearly empty page and JavaScript fills it in. Google can generally handle this, although indexing takes longer. Many other crawlers cannot, including a number of the AI search tools that are beginning to send people to websites. For a local business that wants to be found, this is not a minor detail; it is the very purpose of having a site.
The issue can be corrected through pre-rendering, proper titles and meta descriptions on each page, and a real sitemap. However, you have to know to request these measures, because the tool does not suggest them. If search visibility matters to you, have the technical SEO side reviewed before launch, rather than six months later when you are wondering why the phone is not ringing.
Then there is the work that is not code at all: writing the text, choosing the photos and defining what the site is actually meant to achieve. Lovable will readily build an attractive page that conveys nothing useful.
How can you keep ownership of your code and your domain?
This is the recommendation we consider most important.
Lovable allows you to sync the project to GitHub. Enable this feature, with your own GitHub account, from the first day. Not the account of the relative who helped you set it up, but your own.
The same applies to the domain. Register it in your name, with a registrar whose account you can access yourself, and point it to whichever service hosts the site. If you ever leave Lovable, or it changes its prices, or it is acquired, you move the code, redirect the domain, and your customers notice no difference.
This is one of the oldest problems in small business web projects, well before AI appeared. The web contractor disappears, the domain expires, and no one has the passwords. It was already a familiar situation when our team was building Drupal sites at Raincity. The tools have changed; the problem has not.
How should maintenance be planned from the start?
Every website is a small system that requires regular upkeep. Code libraries are updated. Security vulnerabilities are discovered. Your hours change, your menu changes, you add a service.
With Lovable, minor text changes are simple enough for an owner to make. For any structural change, you will need someone who can read what the AI wrote and confirm that a change in one place did not break something elsewhere. The AI is fast at making edits but less reliable at remembering why things were done a certain way. It may undo a decision you made three weeks earlier because no one informed it that the decision was intentional.
Before you begin, we therefore recommend answering three simple questions. Who will update the content? Who will repair the site when a problem occurs? Who will pay for the hosting and the domain each year? If the answer to all three is that you will, that is entirely acceptable, provided it is clear from the outset.
In which cases do we recommend Lovable today?
For prototypes, simple sites and quick tools, we recommend it without hesitation. It lowers the barrier to a first website more than any tool we have seen since WordPress made blogs easy.
For a business that depends on local search, or that handles customer data, we recommend using it as a starting point and then completing the less visible work on top: security rules, page titles, and real text written by someone who knows the business.
The version produced in an afternoon is real. It is simply not finished.