Post content
One day I was chatting with some friends about Hitster, the game where you place cards with songs on a timeline. They talked about how easy it was for them to remember song lyrics, and from there they jumped to joking about how great it would have been to have songs for studying.
Like many jokes, there was something profound behind it.
Because there's something we know about memory that almost nobody applies: music activates it in a way that reading cannot. Everyone has remembered the lyrics of a song they haven't heard in ten years, but nobody remembers page 47 of any manual.
That's how my idea for TuNotes emerged. And this is what happened next.
tunotes.studio
(MVP prototype)
Before building, think
The first thing I did wasn't design or open an editor. I researched if someone was already doing it. And they were: Studytracks, Lyreka, SynPlex AI. But none with a Spanish presence, and none with personalized generation from your own notes. The market existed. There was an open window.
The first difficult decision was the segment. My instinct was high school: more students, more urgency, more virality. But under-16s in Spain require verifiable parental consent under GDPR-K. I decided to launch with university students aged 18 to 25. They pay for themselves, already use AI, and if the product works with Constitutional Law notes, high school ones are trivial afterwards.
Before writing a line of code I also defined the complete identity: name, color, tone, value proposition. Not as a branding exercise, but because a clear identity is the cheapest decision guide that exists. The principle was one: it should feel like a music app, not a study app. The original primary color was green, almost Spotify green. I discarded it the same day I saw it. I moved to orange. Too much energy, the theme called for something that brought a touch of tranquility. So I finally opted for mint green.
How I built something real with vibe coding
I used Lovable to prototype the complete flow in one morning: no backend, no AI, just screens with static audio. The goal wasn't the code, it was to have something tangible that would make me reflect on whether it really made sense.
Then, Claude Code for the real MVP. What makes this work is the brief. I prepared a technical reference document with architecture, generation pipeline, database schema, prompts, business rules and visual specifications with exact CSS values. With that context, Claude Code built the application routes, authentication system, karaoke player with (approximate, it's an MVP) synchronization and the freemium credits system. Clean build, no critical errors.
People who say vibe coding doesn't work are usually skipping the brief. Knowing what to ask for, and how to ask for it, is 70% of the work.
When reality corrects the plan
The first deploy didn't generate any songs. The message was always the same: "Something went wrong."
A function hadn't been deployed on Supabase. JWT tokens were expiring silently. The ElevenLabs endpoints I was using didn't exist for music: the correct API had been updated in August 2025, and finding it wasn't obvious. The first song arrived after solving a couple of chained problems.
The most important economic blocker also appeared: the cost of audio generation per minute from ElevenLabs. With the initial pricing model, the Pro plan at €5.99 didn't cover costs in any scenario. Currently it's the critical point for launching the app publicly, which is why payments are not currently activated.
Stopping when the model doesn't close, instead of continuing to build, is also a product decision.
Metrics
Before having real users I defined what I was going to measure and why. Not for abstract methodological discipline, but because a poorly chosen metric is worse than not measuring anything: it gives you the feeling that you know something when you're actually looking at the wrong scoreboard. The metric that matters in TuNotes isn't the number of songs generated, but seven-day retention: does the user come back after the first song? If they come back, the product works. If they don't come back, everything else—the genre, the duration, the karaoke—is noise. Generated songs are an activity metric. Retention is a value metric. Only the second tells me if there's something real here.
Marketing
The launch strategy isn't complex because it doesn't need to be. The first ten users should come through direct DMs, faculty WhatsApp groups, study Discord and organic TikTok. There's no paid acquisition budget, it's not needed at this stage: what I need are ten people who actually use the app and tell me what's wrong. I prepared specific messages for each channel, landing page copy with a reproducible demo in the hero—real audio, not simulated—and four songs in different genres so nobody has to imagine how it sounds. The goal of this approach is to get the right people to the product before moving forward.
Guardrails and bullying
There's something that worried me and that I decided to address before building anything: what happens when someone uploads notes that aren't notes. The specific risk is bullying—TuNotes could be used to generate a song that ridicules a classmate or teacher, and in an educational context that's the most serious reputational damage a product like this can have. The solution I implemented is a two-layer defense. First, preflight moderation with Claude Haiku that analyzes the input text before consuming the user's credit: if content is rejected, the credit isn't deducted and the user receives an inline message, in neutral tone and without moralizing. The prompt is calibrated to be conservative—it only rejects when the problem is clear and unequivocal, and approves sensitive academic content like anatomy, criminal law or war history. Second, safety instructions embedded directly in the lyric generation system prompt, as a second line of defense. It's not an infallible system, but it's a thoughtful system.
Where it stands now
TuNotes has a functional application in production, four real demo songs in four different genres, and a technically implemented freemium model. The only real blocker to activate it is the audio generation price, which today doesn't make any reasonable subscription plan profitable.
But generative AI prices have been dropping non-stop for two years, and there's no reason to think they'll stop doing so. For this product I followed the mindset of building now, thinking about what the generative AI market will be like in six months. When the unit economics close, the product already exists.
Parallel to this entire process I developed a marketing campaign, pending activation until ElevenLabs API costs become bearable (or Suno releases an API).
And being honest: I also built it because I had a LOT of fun doing it. Learning how the complete pipeline works—from text to a song with synchronized karaoke—has been tremendously interesting.
If you want to try it, create a free account at tunotes.studio.
IMPORTANT: The song might not generate due to the consumption cost of the ElevenLabs API. In that case contact me at this email and I'll help you try it.
One of my favorite demo songs: The Old Regime of 1789
And how long did it take me to make this?
About 10 days, dedicating a few hours here and there.
Tech stack: Claude Cowork/Code, Linear, Obsidian, Supabase, Vercel, Lovable, GitHub, Anthropic API, OpenAI API (for Haiku fallback), ElevenLabs API, Google OAuth, Stripe.
Don't hesitate to write me if you want more details.