Building an AI-assisted music platform without losing engineering discipline

The actual problem with SoundCloud

SoundCloud is fine for hosting mixes. Upload a file, paste in a tracklist, share the link. What it doesn't really give you is any sense of programming: the idea that a Sunday morning at 7am calls for something different to a Friday night at midnight.

After a few years of uploading, I had a deep archive with almost no way to navigate it. Everything was sorted chronologically. Newest on top, oldest buried. No mood context, no time-of-day filtering, no way to arrive at the site and feel like you'd tuned into something rather than opened a list.

I wanted something that felt closer to a late-night radio station. Not a content feed.

Architecture, kept deliberately boring

The stack is intentionally small. No Kubernetes, no event buses, no frontend framework. The whole thing runs on an RSS feed from SoundCloud as the live event source, blob storage for the enriched mix catalogue, an in-memory cache as the hot path, deterministic recommendation logic, and a vanilla JS/CSS/HTML frontend deployed to Cloudflare.

The last point gets the most raised eyebrows. No React, no TypeScript, no framework. There's minimal build tooling (an env injection step, a dist copy, Wrangler for local Cloudflare Worker dev) but nothing that needs babysitting. The frontend deploys anywhere, has no cold start overhead, and won't need rewriting in eighteen months because the ecosystem changed direction. For a side project with one maintainer, that simplicity has real value.

The frontend is there to make the experience work. The engineering is in the API: the catalogue model, the warmth scalar, the slot-scoring logic, the in-memory cache, the RSS merge strategy. That's where the decisions that matter actually live.

The AI components sit at the edges of this architecture, around the deterministic core.

Recommendations without the ML infrastructure

The recommendation engine is mostly deterministic, which wasn't the obvious choice but turned out to be the right one.

The most useful field in the whole system is a warmth scalar: a float between -1.0 (cold, aggressive, late-night techno) and +1.0 (warm, euphoric, peak-hour house). Combined with BPM, it turned out to be surprisingly expressive. You can describe the feel of almost any DJ mix with just those two numbers.

From there, the Mood Compass (a 2D canvas where every mix is plotted by BPM against warmth) became the most interesting UI experiment on the site. Users drag around the space and discover nearby mixes. It's more like exploring than searching.

The radio scheduling is fully deterministic. Every hour slot has a target BPM, target warmth and target energy profile. Two people loading the page at the same time get the same station. That's intentional. Shared programming feels different to a personalised feed, and for a music context, I think that difference matters.

Design work I had no business doing

The more tightly I constrained the problem, the better the AI-assisted design output got. Specific typography rules, specific spacing, specific colour rules, specific artwork treatment rules. Unconstrained: generic. Constrained: usable.

The visual system for Changsta was built iteratively with Claude Design across radio layouts, compass interactions, catalogue modes and mobile interactions. I have no formal design background. The constraint discipline carried the weight.

Operational automation with a human still in the loop

The maintenance loop is the part I'm most satisfied with. Every day, an OpenClaw agent queries the diagnostics endpoint, analyses any production failures, filters out noise, and turns real issues into GitHub tickets. A second scheduled agent picks one safe ticket, branches from develop, attempts the smallest fix it can justify, runs the build and tests, and opens a PR.

I still review everything. I control feature development, QA, and what goes to production. The agent's job is to reduce the surface area of operational overhead, not to make decisions. The same shape applies to client production systems: AI at the edges of well-defined automation, humans on anything that ships to users.

Adjacent tools

Over time the platform accumulated a few adjacent tools. None of these are products. They're tools I built because I needed them, and they happen to work together.

What this was actually about

I wanted to find out what happens when a backend engineer, working alone, uses modern AI tooling to build something outside their normal area. Design, front-end, editorial voice, operational automation. All of it.

It works, with conditions. AI was most useful when it was operating inside constraints I'd thought about carefully: bounded inputs, grounded outputs, deterministic fallbacks. Every time I tried to use it in an open-ended way, the results were mediocre.

That was the goal.

Tech Stack