Claude Code vs Lovable: Which tool gets your new project idea shipped fastest?
I built a Hitster & Wordle-style daily game to find out
In my last article I sang the praises of Claude Code - within hours I got a non-trivial website up and running. Since my last vibecoded projects almost a year ago, the tools have gotten so much better and faster.
Last week I started a new product role and used Lovable to build a few prototypes to test in user interviews. Lovable has also gotten really good - I especially like using it to make multiple versions of the same page with different copy and styles, like I did with the trash TV website.
That made me think: which tool is better? I decided to put it to the test by using both tools to build an online game. I first built it with Claude Code, and then reproduced it in Lovable using the exact same prompts.
My main lesson: Claude Code wins for building, but I will keep using Lovable for prototype testing.
The new project: Musiqal
Over the Christmas break we always play a lot of boardgames. This year, the party game Hitster was a hit with us.
It works as follows. You start with a single song in your timeline, that was released in say 1975. You then listen to a new song and have to guess if it was released before or after 1975. If your guess was correct, you now also have that song’s year in your timeline. The next guess becomes a bit harder, as there are now 3 possible answers. The first person with ten songs in their timeline wins.
I also really like daily games like Wordle and Connections, where you solve a different puzzle each day. It’s the same puzzle for everyone, so you can compare how well you did.
I started thinking: what is a fun way to combine Hitster with Wordle? What I came up with was Musiqal: you guess the release year of five different songs, scoring more points the closer you are to the correct answer, and the songs update once a day.
I knew there would be a few things to figure out:
Designing a simple UX that is easy to understand and use
Getting the songs (can we do this for free? How do we stream the songs?)
Letting users keep a record of their results (locally? Or via an account?)
Making it easy for users to share their results
Building with Claude Code
I started with Claude Code. I recorded myself rambling some initial thoughts using Wispr Flow:
Claude Code automatically loaded the brainstorming skill from my `superpowers` plugin to clarify some of the open questions. For example, for getting the songs it suggested Spotify, Youtube, self-hosting, or licensing deals. None of these worked for me - I don’t want users to have to sign in to Spotify, and I don’t want to close a licensing deal. I told CC to find other options, which then offered Deezer API as a good solution.
In general Claude Code asked a lot of good questions to nail down the product’s functionality, with clear recommended options that I went for most of the time. It asked a total of 15 questions, including:
Should the songs be randomly picked, themed, or balanced across the decades? [random]
How should the results of anonymous users be stored? [locally in browser data; no account creation possible]
When should users submit their guesses - all at once, or one at a time? [all at once]
How long should each music snippet be? [30 seconds - this is what Deezer provides as a preview]
Should the start of each song play, the most recognisable part, or a random part? [most recognisable part]
Based on these answers it proposed a plan for implementing the game (I used `plan mode` to make sure it first created a plan and let me verify it before diving into building), and even made a little mock-up of what it would look like:
The first version of the website was built very quickly, and looked pretty good!
One major thing it did forget is a Privacy Policy, Impressum (as required by German law) - I had to explicitly ask it for that.
The Admin interface for setting up the songs per day also took a few iterations to get right. One issue was getting the tool to automatically load and pick songs for the next 90 days (versus me doing it manually), and another was that some of the release years were wrong due to re-releases (e.g. Elvis Presley songs in the 2000’s). But eventually I was able to load over two thousand songs, and define the song picks for the next 90 days, with the click of a button!
In the end I pushed the code to Github, bought a domain using Cloudflare Registrar, and deployed it to Vercel. (This may sound intimidating, but after doing it once it becomes straightforward).
To test the game I used it myself for a few days, asked a few close friends to try it out, and eventually posted on LinkedIn about the game - which gave me a few improvement areas (e.g. auto-playing songs, and using MusicBrainz to double-check the release years). So far 65 rounds have been played.
Give it a try yourself at play-musical.com!
Building with Lovable
So, how would Lovable build an app like this? I used the exact same prompt to get started.
The first thing that stood out is that it suggested similar options for getting the songs: Spotify, Youtube, or Apple Music. It claimed that Spotify provides free 30-second previews without licensing. Except… it doesn’t. Spotify stopped offering this in November 2024, as a quick Google search for “spotify preview api” reveals. (Claude Code did know this).
It didn’t even let me choose which of those options to go for. It did ask me some other questions, such as
What music era should the game focus? [1950s - Present]
What’s the vibe for the design? [Modern/Minimal]
Who are you building for? [External users]
After that came a few more questions, but it never went back to the Spotify vs Youtube vs Apple Music choice. In fact, after only 8 questions (versus 15 with Claude Code) it wanted to start building.
After pointing out that it forgot to clarify the music source question, I got the classic LLM apology message (“You’re absolutely right, apologies!”). It still wanted to use Spotify, so I let it proceed to see when it would realise the free previews don’t work anymore. There were also still several other open questions it had never asked me to decide on.
At this point we started building Phase 1 (just the front-end, with fake songs and data). The app it came up with was not bad - kinda similar to what Claude Code came up with, but a little bit less polished to my (non-designer) eyes.
The next step was getting the actual songs to play - which it wanted to do with Spotify. It ended up adding an embed player (see below), which already shows the artist and song. Not quite what we were looking for. Only when I pointed out that Spotify had discontinued the proper preview in November 2024 did it go back on its Spotify suggestion and replaced it with Deezer.
You can find the final result here. It’s a bit buggy and unpolished, and with a few iterations I could probably get it to be closer to what we got from Claude Code. But the first version that Claude Code created was much closer to a final product than Lovable.
My verdict: Claude Code wins
Lovable wasn’t bad - if I didn’t know any better, it would have produced a fine website. It’s just that Claude Code was a lot better:
It really nails asking the right clarifying questions and providing good options
It has more up-to-date knowledge of the tools and APIs available online - Lovable did not know Spotify had discontinued its song preview, which is a major issue
The layout and design system that Claude Code creates looks nicer (to me)
However, Lovable is great at quickly building a website and getting it live. Last week I ran a number of user interviews to test different value propositions and visualisations of the product we’re working on. Within ten minutes I had a website live where the user could click through different options, with AI-generated images to visualise the ideas. And I could deploy and share it with a single click. That’s something that Claude Code can’t do as easily.
So the tl;dr is: use Lovable for prototype testing, Claude Code for building.
Have a great week - and of course, make sure to try out Musiqal!