I built a side project that turns YouTube videos into study notes — here's what I learned shipping solo

Chun Jen Lim — Fri, 01 May 2026 07:07:46 +0000

I'm a game developer. I ship games at a studio for my day job. I thought that would make building a solo web app easier.

It didn't. Not even close.

This is the story of building and launching Lynote — a tool that turns any YouTube video into structured study notes — and everything I wish I'd known before I started.

The problem

I watch a lot of YouTube to learn. Tutorials, conference talks, university lectures, technical deep-dives. I always felt productive while watching. Then I'd go to actually use what I'd learned and realise almost none of it had stuck.

The root cause was obvious in hindsight: passive consumption. Watching isn't learning. Learning requires doing something with the information — summarising it, questioning it, testing yourself on it.

I wanted a tool that would take a YouTube link and give me back a proper study note. Summary, key takeaways, action items, flashcards. Something I could actually use to review and retain what I'd watched.

I couldn't find exactly what I wanted, so I built it.

The stack

I went with what I knew would let me ship fast:

Next.js 16 App Router — file-based routing, server components, clean architecture
React 19 — server actions made form handling much simpler than I expected
Supabase — auth and database sorted in an afternoon, SSR integration worked smoothly
OpenAI Responses API — the core of the generation pipeline
Vercel — zero-config deployment, exactly what you want when you're solo Nothing exotic. The goal was to spend my energy on the product, not the infrastructure.

The interesting technical problem

Getting consistent structured output from an LLM across wildly different video types was harder than I expected.

A 10-minute tutorial has a very different transcript density than a 2-hour university lecture. Short videos would sometimes produce overly padded notes. Long videos would hit token limits or lose coherence toward the end.

I ended up with a two-pass approach for longer content — a chunking pass to extract key segments, then a synthesis pass to generate the final note. It's not perfect but it's consistent enough that the output quality feels predictable regardless of video length.

What I got wrong

I underestimated how long "done" takes. I had a working MVP in about 3 weeks. I spent another 3 months on things I told myself were polish but were actually procrastination — tweaking UI details, refactoring things that worked fine, adding features nobody had asked for yet.

I overthought pricing. I spent days on pricing models when I should have just shipped a free tier and figured it out from real usage data. Token packs are live now. Subscription billing is still not implemented. Ship first, figure out money second.

I underestimated how much the product decisions matter. The engineering was the easy part. Deciding what to show, what to cut, how to structure the output — that took longer than any of the code.

What actually helped

Building something I personally needed — I used the tool every day while building it, which meant bugs bothered me personally and the feedback loop was immediate
Keeping the stack boring — familiar tools meant I never got stuck on infrastructure
Shipping before I felt ready — the version I launched is not the version I wanted to launch, and that's fine

Where it is now

Lynote is live at Lynote. Free tier with 10 notes per day, no account required. Token packs for heavier users.

It's my first solo product launch. If you're a developer who's thought about building something on the side, my only advice is to start smaller than you think you need to and ship faster than feels comfortable.

Happy to answer any questions about the stack, the prompt engineering, or the experience of building solo as a game dev.