My First Vibe-Coded Product: Weather Alert Spain

I wanted to share how I vibe coded my first app with Lovable, which started with a Red weather alert we received in January 2026 whilst I was out hiking with my son. Although I live in Spain I’m not fluent and we were nearly at the rendezvous spot where we were meeting my wife and daughter, so I translated the alert with ChatGPT and called her straight away. The alert read as though it was for the next province, so although I was aware of it I didn’t consider there to be any immediate danger.

Fifteen minutes later I met my wife and her friend. I had fully intended to jump in the car and drive home, but my wife was calm and, as she had no signal, she hadn’t clocked how severe the alert was, so I relaxed and we began talking. Ten minutes later a strong gust of wind hit, breaking branches and sending up a lot of dust. We jumped in the car as quickly as we could and drove home.

Throughout the storm that night I couldn’t stop thinking that I should have known about the weather and taken the alert more seriously. Time and again you hear about people who don’t take these alerts seriously and it can have serious consequences. We got lucky, as a branch could have crushed the car or landed on one of us. The reason I’m not across the alerts is that I’m not tuned into local news because of the language barrier, so I can miss a lot.

From a Make.com prototype to a product idea

The next day I started discussing an approach with ChatGPT and found out that AEMET, the Spanish weather alert service, publishes its alerts as an RSS feed. Within an hour I had a prototype in Make.com that ran my region’s alerts through an AI module and sent me an email once a day with the alert translated into English.

I’m not the only person in Spain who isn’t tuned into local news, so I started wondering whether the same idea would help others. Around the same time I’d been reading more and more about Lovable, an AI coding platform built on natural language prompting, and having heard about Claude Code, Cursor and other platforms I was keen to build something myself. I chose Lovable because I’d read it was a good starting point.

Translating all of the Spanish weather alerts into English and distributing them by email felt like a good first project. It needed users to create an account and log in securely and it needed the system to take the alerts, parse them, store them and send them by email. As a prototype it would test a lot of the basic areas used in products and show me how well they worked in a vibe-coded project.

Writing the spec before building

Having seen lots of Instagram reels about vibe coding with Lovable and similar tools, I knew the biggest problem was people starting without a clear idea and then breaking their product when they changed direction or built the wrong features. I spent a few days defining the exact spec before building anything.

I had the initial conversations with ChatGPT, going back and forth to define the product, and ChatGPT wrote the first version of the documentation and spec. I then refined it with Claude and asked ChatGPT to refine it again until I was happy with the result after reviewing the feedback from both, before bringing Gemini in to refine it further. This saved a lot of experimenting in Lovable and therefore a lot of credits. Getting the spec right before building saves time, money and problems later.

Product decisions in the spec

There were quite a few product decisions hidden inside that documentation. I decided early that Weather Alert Spain would relay and explain official AEMET alerts rather than try to predict the weather itself or give people advice, and that set strict boundaries for the AI. The Make.com prototype had used AI to translate and explain the alert, but I didn’t want it determining whether an alert should be sent, changing its severity or deciding which users should receive it. Those decisions all came from the AEMET data and fixed rules in the application, so the AI could improve the English explanation but if it failed the alert still needed to work without it.

It would also be email-first rather than something users needed to keep checking. Red alerts would be sent immediately, while Orange and Yellow alerts would go into scheduled summaries so people weren’t bombarded with emails, and users could choose which severity levels they wanted and their preferred summary window.

I also decided against traditional username and password accounts. I wasn’t interested in collecting personal information beyond the email address and the preferences needed to deliver the alerts, so I opted for magic links. A user could verify their email, manage their subscription or unsubscribe using time-limited links. SendPulse was selected to handle the transactional emails and alert delivery. This sounded simpler than building normal account management although, as I found out later, there was still quite a lot of security and permissions work needed to make all of the different journeys behave correctly.

Tickets and the build plan

Once the documentation was set I asked Claude to write the tickets. I gave each ticket to ChatGPT to review and went back and forth with Claude until I was happy with the result, then asked Lovable to write a plan. I checked that plan with both Claude and ChatGPT, as both had the full documentation, and updated it before proceeding.

There were 13 core tickets and they built the product in layers. The first few laid the foundations, covering the database and reference data, the landing page, magic-link authentication with the first SendPulse integration and the preferences and subscription management screens. The middle tickets handled the alerts themselves, ingesting and parsing the AEMET feed, applying the routing rules and then sending immediate Red alerts and scheduled summaries. I deliberately ran ingestion and routing without sending any email first, so I could prove the incoming data and inspect what the system thought it should do before connecting it to users.

The last few tickets added the optional AI enrichment behind a feature flag, with a five-second timeout and fixed fallback copy, so switching it off never changed who received an alert or when. They also added a deliberately limited read-only admin view, as the product only had one administrator, and end-to-end testing across real AEMET data, escalations, timezones, deduplication, empty feeds and the full subscription lifecycle.

I was surprised at how quickly the project moved and really happy to see it materialise. My tickets were detailed, so sometimes I left Lovable working for 30 minutes at a time, and it built fast and with direction.

Waiting on external providers

The biggest blocker early on was waiting for the email service to be approved, which took several days. Because access was through magic links, I couldn’t see or test the UI until it was. I was initially blocked and had to provide further evidence, but I was approved a few days later. It’s often the external providers, the parts of a build nobody can control, that cause the delays, and they need factoring into the schedule. The other wait was DNS propagation, although the longest delay there was a caching issue on my end.

Testing with real alerts

Once the email service was approved and I could finally log in, I started testing with real alerts, and the first thing it exposed was my assumption about geography. I had scoped subscriptions at region level, which made sense on paper and made the first version simpler, but AEMET issues alerts for all of Spain, by region and then by what I would call subregions. Where I live there are four subregions, but some regions are huge, such as Castile and León, which has 24 across its nine provinces, so the emails were long and full of detail I didn’t need. I paused the build and reworked the database and the import and parsing scripts. This was complex, as adding tables at that stage was harder than building from scratch, and it took around 100 credits.

Permissions were the next problem. Security around logins and updating notification settings had been built incorrectly and all of the edge cases had to be teased out. Although I wasn’t collecting personal data, users still needed a profile and a secure place to sign up and manage their alerts, which raised questions such as how many times a user could access the site in a given period, what happened when someone created an account and deleted it straight away, and what happened when someone registered and changed their alert in the same login.

Design probably used the most credits of all. I hadn’t specified it from the start, so as my first project I built everything in black and white with no real design, and updating it afterwards was tedious. I ended up using v0 to get the basic design and tweak the layouts.

None of these were really about Lovable being unable to build the application. With geography I had made the wrong product assumption. With permissions I hadn’t gone far enough into the possible user states before authentication was built. With design I had effectively told Lovable that it didn’t matter and then changed my mind once most of the screens existed. Lovable could fix all three, but fixing a bad decision after it had spread through the product was much more expensive than getting it right earlier.

What worked when vibe coding with Lovable

Lovable’s Project Knowledge became very useful once the build got more complicated. I uploaded the requirements, data mappings, security rules and email specifications and referred to those documents directly in my prompts, which worked much better than expecting Lovable to remember every decision from the conversation. My prompts also became more precise as I went along, specifying what I wanted changed and also what I didn’t want touched. By the later stages each prompt pointed Lovable at the relevant document and set clear limits on what the change could touch, rather than describing what I wanted and leaving it to interpret the rest. On a similar project I would set both of these up much earlier.

Cost and users

The MVP cost around £100 in total, of which £52 was Lovable credits I bought at half price on Valentine’s Day. That is a lot less than an MVP would have cost a few years ago. As of September 2026 Weather Alert Spain has seven users, all organic, as I haven’t spent any time on marketing.

What I took from my first vibe-coded product

Coding wasn’t really the skill here. I drew on my years in product management, and having worked with developers who each bring their own opinions, ideas and expertise, I found the same with AI, except that I had the authority to overrule it, make my own mistakes and fix them.

The building itself was incredibly quick. The time went into defining the product, understanding the data, working through edge cases, testing what had been delivered and realising when one of my own decisions was wrong. The difference was that once I’d made a decision I could put it into the product almost immediately and see whether it worked.

It has also changed how I find out about the weather where I live. If another Red alert is issued for my area, it will arrive in my inbox in English and for my own subregion, alongside the Spanish notification on my phone, so I won’t be translating it and working out whether it applies to me while I’m out on a hike with my son.

If you live in Spain and want AEMET alerts in English, you can subscribe at weatheralertspain.com.