Mixtape: A Case Study on how to plan, research, and ship with Claude

What I built

Mixtape lets you make a mixtape on the internet. You pick tracks, you arrange them, you save the tape, you send the link to someone you love. They press play.

It lives at mixtape.uristocrat.com.

Why I built it

Two reasons. I wanted to make a mixtape for my wife to celebrate our daughter's first birthday, in the style of recording songs off a radio station and saving them to a cassette. An Apple Music playlist did not feel like the thing. A playlist is a list. A mixtape is a letter. That tape is here.

The second is the reason this case study exists. I wanted to see how far planning, research, and Claude could get me on a real app in two evenings. A working thing with a URL, pulling real tracks from the services that actually own the music, that the person could open on their phone.

The plan

The plan started with the shape of the thing because I wanted to recreate the feeling of a cassette mixtape. I wanted it to be nostalgic, and something with a little weight to it. I wrote that plan as a Claude prompt, and what I learned writing it fed back into how I plan engineering work now.

The research

Then I went and looked at what was actually possible. I researched Apple MusicKit to see what it would let me do. The answer was enough to start: I could search for tracks, add them to a tape, and play them back. That is the whole core of a mixtape, so that is where I began.

One gotcha shaped the player directly. Apple Music only lets you play 30 seconds of a track through the API if you are not logged in, so the player has to handle both states, logged in and logged out. Apple Music runs the subscription checks itself, so I did not have to build any of that. I learned this in the research, not halfway through the build, so I designed the player around it from the start.

Shipping it with Claude

With the core decided, I scaffolded a UI with Claude that showed the experience end to end: search a track, add it to the tape, play it back. Once that felt right, I shipped.

After it shipped, the feedback was immediate: add Spotify. Adding the Spotify Web API came with its own gotcha, and it was not the code. It was their developer portal. The slow part was working out which permissions the app actually needed and getting the right scopes set, not writing the integration. Same lesson as the Apple Music limit, in a different spot: the hard part of a real API is rarely the code. It is understanding what the provider will let you do, and where they make you ask for it.

How it works

The shape of the build is two music services wired in differently, which is the part I would not have known to design without the research.

Apple Music runs in the browser. The Cloudflare Worker only signs a developer token, and MusicKit JS does search and playback directly against Apple. Logged in, you get full tracks. Not logged in, 30-second previews.

Spotify is split. The Worker holds the credentials and proxies the search, so the secret never reaches the browser, but playback stays client-side: the search returns a preview URL and a plain HTML audio element plays it.

Both end up capped at 30 seconds, for different reasons. Apple, because you are not logged in. Spotify, because the credentials I use only return previews. The tapes themselves are saved to Cloudflare KV.

What it took

Two evenings, start to finish. The core came together against Apple MusicKit on the first evening. Spotify, sharing, and analytics came on the second, after it shipped and people started using it. The stack is deliberately light. It runs on Cloudflare Workers, with the tapes stored in Cloudflare KV, and there is not much more to it than that. The weight of this project was in the two API integrations, not the infrastructure.

The bottleneck was never the idea or the code. It was the gap between knowing what I wanted and having a working thing that talked to real APIs. Planning and research closed most of that gap before I wrote a line, and Claude closed the rest.

The takeaway

The process is the product. Whether you are building something new or rebuilding how your business runs, the move is the same. Start with the shape of what you want. Research what the tools and the APIs will actually let you do. Build the smallest real version with Claude. Then let real use tell you what to add next.

That is how you build an AI-native product. It is also how you take a workflow you run by hand today and move it onto AI, which is the higher-value version of the same skill. People call that AI transformation. It is the same loop I ran on Mixtape, pointed at something that makes money instead of something that makes someone smile.

It is also the exact structure of the VibeShift camp. Plan, research the real constraints, ship with Claude, deploy to Cloudflare, then iterate. Mixtape runs on the same stack the camp ships to, Cloudflare Workers and KV, so it is that loop start to finish. The camp is where you learn to run it on the thing that actually matters to your work.

If you just want to make a mixtape for someone, the link is mixtape.uristocrat.com. It is free. There is no signup. Send them the link when you are done.