An application to Spotify

I built the music product I couldn't stop thinking about.

Sliders: an audio embedding model I trained myself, a map of everything I've ever heard, and a recommender to explore it.

How it's built

I trained the models myself.

Not an API wrapper. The representation the whole product stands on is a model I built, trained, and serve — with no catalog, no data platform, and no listening graph to lean on.

The audio embedding model

A 38M-parameter Transformer that reads a track as a sequence of audio segments and trains by predicting masked-out segments — no genre tags, no metadata. The hard part was keeping the embedding space healthy: the loss explicitly rewards isotropy, because without that pressure the space collapses — and the map with it.

The recommender

A two-tower retrieval model: one tower encodes a set of anchor tracks into a query, the other projects the whole catalog, so the best continuations come back in a single dot product. Its track tower begins as a frozen pass-through of the audio embeddings, so the model starts out knowing how tracks sound; only once the queries are good is the projection allowed to move. It drives the constellations — a sensible next track, not just the nearest one.

The ratings predictor

For every slider you invent, a ridge-regression head learns what your word means from a handful of ratings, scored by exact leave-one-out cross-validation. Ambivalent middle ratings are down-weighted as weak signal — which roughly tripled rank quality on the hardest sliders — and a gate keeps a slider dark until it can genuinely predict.

Browser

React 19React Router 7deck.gl map
SSR · fetch

Web

NestJSPostgreSQLTypeORM migrations
Tailscale · bearer token

Data machine · GPU

Python / FastAPIPyTorch embeddingsper-slider ridge headstwo-tower recommenderUMAP projection

The stack, end to end

The web app is one Node container — React 19 + React Router 7 (SSR) with a deck.gl WebGL map, served by NestJS, backed by PostgreSQL and TypeORM migrations. Behind it, a separate Python / FastAPI service on a home GPU box serves the PyTorch embeddings, per-slider training, recommendation, and the map projection — reached over Tailscale, so no model weights ever touch the web tier.

React 19React Router 7 (SSR)NestJSPostgreSQLTypeORM migrationsdeck.gl / WebGLPython / FastAPIPyTorchTailscaleDocker / Coolify192 e2e tests

The story

A fifteen-year obsession my skills finally caught up with.

The idea arrived essentially complete in 2011: I loved endless algorithmic radio and hated that a thumbs up or down was all I could say back to it. I wanted to tell the engine why a track fits — sliders were the answer. And I could see the whole shape from the start: make the player genuinely good, and people would invent sliders, share them, rate on them — every rating making the engine smarter. That's what started the obsession.

I built the first version in 2015 — a crude prototype that won an accelerator and got real people rating real sliders. But it couldn't learn yet, and I was in it for the tech, not a business model — so I had to find a day job, and Sliders became the hobby of my evenings. Years of learning each piece deeply enough to one day build the whole thing myself, and a growing bookshelf of experiments, each one just to test my understanding of a single technology.

Then AI collapsed the timescale. On May 1st I scheduled a week-long hack-ation and took one more shot at turning it into a real product. I didn't finish in a week. But the loop I'd run for fifteen years — learn, build, test, fix the next thing — had never spun this fast. The result is the app you can try today: the whole idea at last, built by one person and a home GPU box.

The fit

Why this is the work I want to do at Spotify.

Ambiguity and ownership

I took an open-ended idea, crystallized it into a clear vision of how every piece fits, and owned it end to end — model, backend, frontend, and deployment — without a spec to hand me the answers.

Practical AI

Sliders went from first commit to production in about two months, because I put agents through the whole SDLC: they wrote most of the code and ran the auto-research that tuned the models. The multiplier is engineering judgment — knowing exactly what to build, and which work to accept.

Music, specifically

Sliders isn't a demo built for this application — it's the product I wanted to exist, and I use it every day. Music is the problem I keep returning to, and Spotify is where working on it stops being a side project.