Deep Cut
Deep Cut is a mobile-first music application that identifies any song playing in the room and generates a behind-the-scenes editorial on the spot: band history, the story behind the track, critical reception, and deep lore. Start listening and then read the story behind the song.
Deep Cut is Live
Deep Cut is a working prototype in active development. Try it out on your phone. Identify a song that's playing then dig deeper.
The Concept
For music lovers, there’s that moment when you hear a song and something clicks. You need to know what it is, who made it, where it came from. Shazam tells you the name. And then it stops.
Deep Cut starts where Shazam ends.
The premise is simple: let your phone listen to a song playing in the room, and receive a behind the scenes editorial on the artist and that specific track: band history, the story behind the song, critical reception, controversies, trivia, and deep lore. The kind of insights that makes you feel like you know something now that you didn't before.
Deep Cut is a mobile-first application, designed to live in your hand in the exact moments when music catches you. The aesthetic target was equally specific: a premium music publication that fits in your pocket. The warm, analog palette and editorial typography of a record shop after hours. Nothing clinical, nothing social. Just the song, and the story behind it.
What This Project Had to Prove
Deep Cut was built as a portfolio project with a specific thesis: that an AI-native application can produce writing that feels earned rather than generated. Most AI content tools produce recognizable output: fluent, complete, but lacking depth and soul. Deep Cut's editorial layer had to feel like it was written by someone who actually cared about the music.
The Core Loop
User holds phone up and lets it listen to a song playing in the room
App records 7 seconds of ambient audio via the browser's native MediaRecorder API
Audio is fingerprinted and matched via AudD
Claude generates a rich editorial narrative, streamed progressively to the screen
User reads a full magazine-quality write-up: the song's history, reception, controversies, and lore
Guided Demo
Designing for the Music Obsessive
Every color in the app is meant to evoke analog warmth.
The foundation is near-black ("void," #0C0C0C) and warm off-white ("cream," #EDE9E0). The contrast is high without the clinical sterility of pure black and white. The sole accent is ember (#B85C38), a burnt orange that appears on section labels, interactive states, and the logo.
One additional texture decision: a fixed SVG fractal noise overlay at 2.5% opacity covers the entire application. Imperceptible consciously, yet tactile.
The Editorial Engine
Voice
The system prompt establishes a specific editorial character. The model is addressed as a music journalist writing for a premium platform — one with deep knowledge, genuine passion, and a voice that is its own: intelligent, occasionally witty, never neutral.
The prompt doesn't just describe a persona. It describes how that persona thinks. Specific writing instructions accompany the framing: avoid Wikipedia-style hedging and passive voice; use real dates, real publications, real names rather than generalities; have a point of view.
The challenge wasn't making the content accurate. It was making it feel like it was written by someone who actually cared about the music.
Five Sections
Every article is structured identically. Five sections, always in the same order, always in the same visual format. The structure is the magazine.
Zero Infrastructure
There is no database. There are no user accounts. There is no persistent storage layer. This was a deliberate constraint, not a limitation to be solved later. The architecture matches the product: one song, one article, one session. No history to browse, no favorites to save, no feed to populate.
The simplicity of the data model reflects the simplicity of the experience. Every technical decision was made in service of the core loop — and the core loop had no use for infrastructure.
Streaming as a Design Decision
Content does not wait until fully generated before displaying. Each of the five article sections appears on screen as Claude finishes writing it, with skeleton bars holding the layout in place while the next section generates. The first words arrive in two to three seconds.
Without streaming, a user stares at a blank screen for ten to twenty seconds. With it, the experience feels like watching a writer think. This is not primarily a performance optimization — it is a choice about what kind of experience this should be.
Getting the Microcopy Right
The original home screen label above the microphone button read "What's that song?" It was conversational and warm, and it mirrored what a user might actually be thinking in that moment. But it was solving the wrong problem.
The microphone button is self-explanatory — users understand intuitively that tapping it will identify the song. The real gap for a first-time user isn't recognition; it's expectation. They don't yet know that what's coming is a full editorial, not just a song title. "What's that song?" did nothing to set that expectation.
The revised label, "Hear a song. Read its story," addresses this directly. It frames the app's two-act experience in the simplest possible terms: something passive happens (you hear something), and something rich follows (you read about it). The verb "hear" puts the user in the right moment — caught by a song mid-stride — rather than framing identification as a task. And "read its story" signals that what's coming is worth reading, not just a lookup result.
Guardrails Are Not Optional
The most important lesson from building Deep Cut is that generating editorial content with a language model requires deliberate accuracy guardrails — and that those guardrails need to be designed, not assumed. A well-crafted system prompt shapes register and voice effectively. It does not, on its own, prevent the model from stating something confidently that turns out to be wrong.
The clearest example surfaced during testing with cover songs. When the audio fingerprinting service returned a match on a cover rather than the original recording, the model had no way to detect the discrepancy. It generated a full, fluent editorial — band history, story behind the song, critical reception — attributing the song's creation to the cover artist entirely. The writing was good. The premise was wrong.
That failure pointed to a gap in the system design: the model was treating the fingerprinting result as ground truth and reasoning outward from it, rather than cross-checking the identified track against what it knew about song provenance. A more robust architecture would include a verification pass — either prompting the model to explicitly confirm whether the identified artist is the original composer, or using a structured data source to flag covers before content generation begins.
Accuracy and Voice Are Separate Problems
This distinction matters for how the product should be built going forward. The prompt engineering work done to shape voice, register, and specificity is real and it works. But voice is not the same as factual reliability, and solving for one does not solve for the other. A future version of Deep Cut needs a fact-checking layer that is architecturally separate from the editorial layer — so that the model's confidence in its writing doesn't paper over uncertainty in its sources.