Building an AI Community Jukebox Overnight (and What Broke by Morning)

The $50 Challenge

A few days ago I got accepted into the MiniMax developer program. The email was short and direct: here's a $50 API voucher, we're curious to see what you'll build. That's it. No strings, no required deliverable, just fifty dollars and a question.

Some context on me: I've spent 15 years building backends, data platforms, and pipelines. I'm comfortable with databases, APIs, infrastructure — the stuff nobody sees. What I've never done is build something consumer-facing and try to get people to use it. Never marketed a product, never asked anyone to pay for something I made. That whole muscle is atrophied, if it ever existed.

So I made a bet with myself. I'd use the MiniMax credits to build a community feature for my personal site — an AI-powered jukebox where visitors could generate music tracks and interact with each other's creations. Then I'd try to sustain it through crowd-funding. If I can't convince a handful of people that this is worth keeping alive, there's probably no point trying anything more ambitious on the commercial side.

The other piece of context: I didn't build this alone. Claude Code was my coding partner through the entire process. I'm going to be transparent about that from the start because the human+AI dynamic is a big part of this story. What I directed, what I caught, where Claude surprised me, where it fell short — that's all in here. This isn't a hype piece about AI-assisted development. It's a report from someone figuring it out in real time.

Here's how four sessions across one night and one morning turned a $50 voucher into a live community feature.

From Zero to Jukebox

Session one started around 11pm on a weeknight. I had a rough idea: visitors type a prompt describing a song, MiniMax generates it, the track shows up in a public feed. No accounts, no logins, just show up and make music.

I described the vision to Claude and it scaffolded the full architecture in one pass. The first commit touched 30 files: 11 UI components, 5 API routes, a Supabase edge function for music generation, database migrations, and 106 tests. One commit.

The core generation flow uses a fire-and-forget pattern. A visitor submits a prompt, the API creates a pending track in Supabase, then triggers an edge function that calls MiniMax's music-2.5+ model. When generation completes (usually 30-60 seconds), the edge function updates the track status and stores the audio URL. The visitor's browser polls for updates.

One decision I made early: no user accounts. Visitors interact anonymously, identified only by a daily-rotating hash of their IP and user agent. This keeps things frictionless while still enabling per-visitor rate limiting. It was also a deliberate privacy stance — I don't want to know who my visitors are, and I don't want their email addresses. I need just enough identity to prevent spam and enable reactions, not one bit more. A daily-rotating hash gives me exactly that. It means fire reactions reset every day, which I initially saw as a bug but now see as a feature: tracks have to earn their fires fresh each day.

Here's the visitor hash — it rotates daily so there's no persistent tracking:

export function getVisitorHash(request: Request): string {
  const forwarded = request.headers.get("x-forwarded-for");
  const ip = forwarded?.split(",")[0]?.trim() ?? "unknown";
  const ua = request.headers.get("user-agent") ?? "unknown";
  const salt = getDailySalt();

  return createHash("sha256")
    .update(ip + "|" + ua + "|" + salt)
    .digest("hex")
    .slice(0, 16);
}

The UI followed the site's "Ember" branding — dark background, warm cream text, that #c75c2c accent color. Claude nailed the terminal aesthetic without me having to micro-manage component styles. The track cards show a waveform visualization, playback controls, and the original prompt. It even matched the monospace vibe of the rest of the site without being told to. It looks like it belongs, which is more than I expected from a first pass.

Around 12:30am I generated the first track. I typed "lo-fi jazz for debugging at midnight" and waited. Thirty seconds later, a piano riff with brushed drums started playing through my laptop speakers. It sounded... good? Like, genuinely good. I sat there for a minute just listening, slightly stunned that this worked on the first try. The apartment was dead quiet except for this warm little piano loop bleeding out of my laptop, and I remember thinking: I should be asleep, but I don't want to stop this.

That feeling wore off quickly. Because the next thing I had to do was actually review what had just been committed.

The Vibe Coding Reality Check

Thirty files in one commit. Let's sit with that for a second.

I didn't write those files. I described what I wanted, reviewed the output, asked for adjustments, and approved the result. But the actual keystrokes, the architectural decisions at the function level, the naming conventions, the error handling patterns — those came from Claude. My role was more like a tech lead doing a very fast code review than a developer writing code.

This is the part of AI-assisted development that doesn't get talked about enough. The speed is real. But the speed comes with a specific cost: you're now responsible for code you didn't write and don't have muscle memory for. You can read it, understand it, even approve it — but you didn't think it into existence line by line. That gap matters when something breaks at 2am.

I did double-check certain things. The Supabase Row Level Security policies got a careful read — that's where data leaks happen. The rate limiting logic got scrutinized. The API route handlers got a pass for obvious injection vectors. But did I trace every component's render path? No. Did I verify every edge case in the 106 tests? Also no.

And about those 106 tests — Claude wrote those too. They pass, they cover the main flows, but when I actually sat down to read through them, I found the coverage was thinner than it looked. There were twelve tests on the track card component that all tested slight variations of rendering props, but not a single test for what happens when the audio URL comes back null from MiniMax — which is a real failure mode listed in their API docs. Green checkmarks, blind spots. A test suite that gives you confidence without earning it is worse than no tests at all, because at least with no tests you know you're flying blind.

Vibe coding has a debt that comes due when something breaks. If you don't understand the code well enough to debug it without AI assistance, you haven't saved time — you've borrowed it.

I spent about 45 minutes after that first commit just reading. Not fixing anything, not even taking notes — just building a mental map. I traced the generation flow from form submission through the edge function and back. I found one place where an error in the MiniMax callback would silently swallow the failure, leaving a track stuck in "generating" forever. I flagged it, Claude fixed it in one shot. That 45 minutes probably saved me a 2am debugging session later. That's the tax. It's real, it's unavoidable, and anyone telling you AI-assisted development is "10x faster" is probably not counting it.

---

This is where the story gets interesting — the community reactions system, the production debugging saga at 10am, and the crowdfunding experiment. Read the full post on datagobes.dev →