100 Days of Gen AI: Day 46

I tried out Lovable.dev for the first time. I always have a long list of code project ideas handy so I picked one out of my list to try and build it. Here’s an overview of my first experiences with Lovable.

Here’s the project idea, as copied from my notes app:

I started out with an initial prompt:

“I’d like to build a mobile app that can function as a recommendation tracker. I often get recommendations from friends for a book to read, or a movie to watch, or a TV show to try, or a recipe to cook. I’d like to track 1) the recommendation, 2) who it is from, 3) why they liked it, 4) any other notes about it such as where to find it. I’d like to use Go as the server backend language and have no preference on the frontend.”

Within a few minutes I had the rough skeleton of the app I imagined. It chose React and Typescript for the front-end code, and there was no backend code at all. This was pure front-end, with no server or any data persistence. It seemed to get further from this single initial prompt than Replit had in my testing a few weeks ago.

first draft landing A first draft of the landing page

first draft add A first draft of the Add Recommendation page

I asked it to persist user recommendations, which it claimed to have implemented. After some confusion I realized it was only saving them in-memory and not to any real database. I had to ask very explicitly for it to setup data persistence that would be durable across sessions and devices.

It prompted me to setup the recommended integration with Supabase, an open-source Firebase alternative. I started by setting up user authentication via email/password, which was seamless and worked out of the box within minutes. (I remember how long it took me to setup AWS Cognito for GoWishbone in 2021 — it required at least several hours, if not days, to get properly configured.)

Lovable modifies the database schema by proposing SQL commands and asks for approval to run them. I haven’t written raw SQL in years, but I can generally understand what I’m reviewing before approval. Lovable may be no-code, but it still requires reading code/SQL occasionally.

SQL commands

Later on in my development it suggested a SQL command that would have allowed a user to see every other user on the platform. Definitely not something we want! It seems imperative to read these SQL commands very carefully and make sure the Lovable agent is not doing something unintended. Approving the wrong SQL suggestion seems like an easy way to accidentally leak user data.

dangerous sql

I then went to work on persisting saved recommendations. Throughout this project, Lovable would often claim it had enabled saving data to a database, but actually had not. I had to be very explicit and tell it something like “create a database table called ‘custom_categories’.” When given a command it would default to frontend-only changes, as it seems most comfortable with that medium. Any changes to the database it would avoid unless explicitly asked. This caused some confusion for me where I thought something had been implemented but actually had not.

I also found it would occasionally make false claims, or at least implement changes that were not reflected in the visual experience or in the functionality.

False claims Claiming that something was implemented that is clearly not reflected in what is presented to the user

There doesn’t seem to be any built-in feedback loop back for the Lovable AI agent, either via unit tests, screenshots of the app, or virtual users that exercise the app. This means it’s imperative for the developer to carefully test, take screenshots and engage in a back-and-forth with the AI agent until an issue is corrected. I found that in practice I experienced an even mix between one-shot success, and 2-3 turns to get to success. In at least two situations the Lovable agent could never resolve the issue. In those cases, after much frustration and no results, I just moved on.

I noticed there is no conception of dev/prod when it comes to the database. There is a conception of a “preview” mode when working in Lovable to develop your app, and then you click “publish” when you’re ready to deploy. However, they are both using the same database! If you apply the wrong change to the database schema while developing you are very likely to break your production app.

While I was quite impressed with the results in the early iterations, I found several regressions introduced over time. This seems like an inevitable outcome when there is no automated testing.

I also found that while the initial interactions were impressive. It really struggled to add small features, or fulfil detailed requests about desired behavior. This tool seems great for building an MVP, but I wonder how well it can perform as an application gets larger and more complex. As an app grows, perhaps it will need to move to a tool like Cursor which is better designed for professional development across a large codebase.

I got pretty far in my development before it told me I was out of credits on the free tier and would need to sign up for $20/month to continue. $20/month is definitely worth it. Lovable helped compress two weeks of work into a few hours.

In order to deploy my app, I wanted to set it up with a custom domain, which I found is not natively supported.

no custom domain No support for custom domains.

Overall I’m quite impressed. I was able to build an mvp in 90 min.

mvp start The time of my first prompt.

mvp finish The time when I considered the MVP complete (or at least good enough to put in front of a user).

I was able to build this without writing a single line of code. The most technical thing I needed to do was to review the SQL prompts, and occasionally suggest possible types of bugs/issues to check when it got stuck. I kept building features for another few hours after hitting MVP because it was so fun!

Overall a great experience. Some areas I would look to for future improvements:

You can see it live here: