Falling in Love with Lovable

After building Weather Alert Spain, I was keen to build more and I was genuinely impressed with Lovable as a way of building a product. I had spent around £109 getting the weather app to a stable MVP and, although I still had plenty of work to do on it, I was pleased by how quickly I had managed to turn an idea into something real. Conveniently, Lovable ran a half-price credit offer for Valentine’s Day and by this point I already had several other product ideas going around in my head. I did not want to overdo it and buy credits just because they were discounted, but on 14 February I bought 400 additional credits for €60, saving €60, with my next projects in mind.

Not long afterwards, Lovable announced that it would be completely free for 24 hours on International Women’s Day, Sunday 8 March, as part of its SheBuilds initiative. I had around a week and a half’s notice and immediately started thinking about how much I could realistically get out of the day. Rather than simply use it to continue working on the weather app, I decided to rearrange my plans and see how far I could push the platform.

Building two products at once in Lovable

The initial build of Weather Alert Spain had been considerably easier than I expected. There had been problems, wrong turns and plenty of things to finesse afterwards, but one thing that had surprised me was how long Lovable could spend working on a reasonably substantial request. Sometimes I would submit a ticket and it would be building for 10, 15 or even more than 20 minutes, which gave me plenty of time to work on something else while I waited.

That made me wonder whether I could build two products at the same time. I have two monitors, so my slightly ridiculous plan was to have a Lovable project open on each screen alongside separate instances of Claude and ChatGPT. At this point I was still using the browser-based AI interfaces rather than Claude Code or anything more advanced, so in theory I could submit work to one product, switch to the other while Lovable was building, review the results there and keep moving between the two.

I already had two products in mind. The first became Pass PM Exams, an update to a Scrum PSPO practice app I had originally built in Lovable for my own use while studying for the Professional Scrum Product Owner exam in November 2025. This had actually been the first real product I had vibe coded and, while studying, I had built up a large question bank that I thought could be useful to other people. My idea was to turn it into a proper live product, offer a useful free version and potentially sell access to the larger question set for a relatively low one-off price.

The second idea eventually became AI Splicer. I had noticed that more and more of my work involved very long conversations with AI and some chats were ending up thousands, or even tens of thousands, of words long. Although there was normally a lot of useful information in them, finding something afterwards could be painful because I was scrolling through pages of repeated thoughts, discarded approaches and answers spread across different parts of the conversation. I wanted something that could take those long conversations and turn them into useful structured summaries, pulling out the actual answers and decisions without me having to search through the original chat.

Planning before building

I followed broadly the same approach I had used for Weather Alert Spain, although this time I went further with the preparation. I started with long conversations in ChatGPT to work through each idea and produce a PRD, then brought Claude into the process to challenge the thinking, verify parts of the plan and help me create the additional documentation I needed. The two products required quite different structures, so I did not try to force exactly the same documentation onto both of them. AI Splicer needed more thought around how the content would be processed and what the output should look like, while the Scrum product needed clearer rules around question banks, attempts, scoring, payment and user access.

I also wanted to solve one of the biggest problems I had encountered with the weather app, which was starting with an essentially undesigned application and then trying to retrofit a coherent design afterwards. Lovable could create perfectly acceptable screens from a basic prompt, but once I had built several pages independently it was much harder to make the whole thing feel like one product. This time I wanted the design to be much more settled before development started, so I worked with Claude to define the visual direction, mock up components and create example HTML pages that Lovable could use as a reference.

There was a reasonable amount of effort involved before the free day even started, but by Saturday evening I felt ready. I had created both projects in Lovable, uploaded the documentation and made sure that my initial build tickets were prepared and in a sensible order. The free period started at midnight, but I had no desire to work through the night, so I went to bed and got up at around 7am on Sunday ready to see whether the plan would actually work.

Two screens, two products

The organisation was probably as important as the documentation. I needed to make sure that I always knew which Lovable project, AI conversation and set of requirements I was looking at because a careless copy and paste into the wrong browser window could easily send one of the products in a completely different direction. Once I had everything arranged properly, though, the process worked surprisingly well. I would submit a reasonably substantial piece of development to one project, switch to the other, review what Lovable had produced there, test it, discuss any problems with Claude or ChatGPT and then submit the next piece of work.

Things moved very quickly. Because so much of the thinking had already been done, I was not spending the morning deciding what I wanted the products to do. Pages and workflows that had existed in documents the day before were suddenly appearing and working in front of me, and I could see both products developing side by side. This was really the point where I fell in love with Lovable. I had already been impressed by Weather Alert Spain, but watching two completely different products take shape at the same time was something else.

By around halfway through the day I had already reached much of what I had originally considered to be the MVP for both products. That was good progress, but it also created a new problem because I was quickly moving beyond the work I had carefully planned.

Context switching between two products

As the day went on, I started to find the whole thing surprisingly tiring. Following prepared tickets across two products was relatively easy because the decisions had already been made, but product development never follows the documentation perfectly. Once you see something working, you notice things that are wrong, think of better approaches, hit technical constraints or realise that something which looked sensible on paper does not work as well in the actual product.

Normally I enjoy that part of the process because it is where a lot of useful product thinking happens, but solving those problems across two entirely different products at the same time required a lot of context switching. One minute I was thinking about Scrum exam attempts, question banks and access rules, and a few minutes later I was thinking about transcript processing and how the AI outputs should work together. I was also trying to maximise the free day, which meant there was a constant temptation to keep something building rather than stop and think properly.

At one point I had to take a break and went out for a walk because my head was starting to hurt. I also encouraged my wife and son to have a go with Lovable themselves. It was International Women’s Day and I was conscious that leaving my wife with the children for the entire day while I sat building software was probably not quite in the spirit of the event. My son built a small game and my wife experimented with an app idea of her own, which was another interesting part of the day because it showed how accessible this kind of development had become. Neither needed to understand traditional software development to start turning an idea into something they could interact with.

When the plan ran out

The most interesting part of the day probably came towards the end, when I effectively ran out of prepared tickets. I had built much more quickly than I expected and reached the point where the work I had properly thought through had largely been completed. The sensible thing would probably have been to stop, review what I had and plan the next stage properly, but development was free and I wanted to get as much out of the day as possible.

This was where things started to become less effective. The planned development had worked really well because each request was backed by documentation and decisions I had already made. Once I moved beyond that, I started creating scope while I was building and reacting much more to what Lovable had just produced. Some of that work was useful and led to good ideas, but it was noticeably less considered than the earlier part of the day.

I also stopped trying to move both products forward equally and eventually spent more of my time on AI Splicer. It had already grown well beyond the simple summary tool I had first imagined, with transcript ingestion, chunking, AI analysis and synthesis starting to take shape. By the end of the day I had even started looking at security and hardening parts of the workflow, areas I would normally have expected to deal with much later.

I also noticed that removing the cost constraint changed how I was building. Normally every extra piece of development had a visible credit cost attached to it, which naturally made me stop and think about whether something was worth doing. For one day that constraint had disappeared, and it became very easy to move from asking whether something was the most important thing to build next to simply asking what else I could get built before midnight.

Two working MVPs in a day

I had sat down at around 7am with two prepared projects and by the end of the day I had two detailed, working MVPs. Pass PM Exams had free and premium access in place and Lovable was committing work on rate limiting, usage logging, SEO and scraping protection late into the evening, while AI Splicer could ingest and process long transcripts and produce structured AI-generated outputs. Neither product was finished and I spent time over the following weeks testing them, fixing problems and finessing the experience, but both were usable products that I could continue developing.

Eventually both were parked for a while because I kept returning to Weather Alert Spain and other ideas moved higher up my priority list. I had reached the point where I could build products faster than I had the time to properly launch, operate and improve them. I returned to both later in the year with a much clearer idea of what I wanted from them and I will cover each separately because there is considerably more to say about how they developed.

The free Lovable day was probably the moment when my view of AI-assisted development properly changed. A month earlier I was still testing whether I could genuinely build a useful product in this way, whereas by 8 March I had two products developing side by side and had built most of what I planned before the day was even over.

The biggest lesson came when the tickets ran out. While I was working through properly planned requirements, Lovable was incredibly effective and moved much faster than I expected. Once I carried on simply because development was free, the quality of my decisions started to fall. The technology was still moving at the same speed, but I was no longer giving it the same quality of direction.