Case study
In progress
Kocteau
2026 / Product design + engineering
A social music case study around reviews, taste onboarding, Deezer-powered search, public profiles, track pages, and a Supabase/Postgres backend.
Stack
Problem
Music discovery is personal, but most music products optimize playback, cataloging, or passive recommendation. Kocteau explores a more social question: what would a Letterboxd-like layer for songs feel like if reviews, taste, and discovery lived in the same product?
Kocteau is built around a simple belief: music taste becomes more meaningful when people can explain it, not only stream it.
Playlists show what people collect, scrobbling shows what people played, and algorithms suggest what might come next. But the human layer often disappears into group chats, social posts, or notes that are hard to revisit. Kocteau turns that behavior into a product loop.
Solution
The core loop combines explicit taste with social activity. A user signs in with email OTP, completes a profile, selects preference tags, reviews songs found through Deezer, and then discovers more music through reviews, follows, and feed signals.
- Step 01
Sign in
A passwordless OTP flow lowers account friction and keeps the first session focused on taste, not credentials.
- Step 02
Shape taste
Profile setup and preference tags create the first recommendation signals before the user has review history.
- Step 03
Find a track
Deezer search gives users a fast way to find music while Kocteau decides what needs to become local data.
- Step 04
Publish a review
A rating and written take turn listening into a reusable object attached to a profile and a track page.
- Step 05
Interact
Likes, bookmarks, comments, and follows make the product social and create richer signals for discovery.
- Step 06
Recommend
The feed can blend preference tags, social signals, recency, diversity, and fallback content as usage grows.
Architecture
I treated Kocteau as a product system, not a static demo. The architecture separates UI, server state, backend data, auth, external music metadata, and deployment. Access rules lean on Row Level Security so public social surfaces and private user actions can share the same relational model.
Technical decisions
OTP-first authentication
- Problem
- A social product needs low-friction account creation, but handling passwords adds security and UX overhead early in the MVP.
- Decision
- Use Supabase Auth with email OTP and pair onboarding with profile and taste setup instead of password creation.
- Tradeoff
- The app avoids password management, but email delivery, expired codes, and redirect states need careful testing.
Entity caching layer
- Problem
- Deezer is useful for search, but relying on an external API as the source of truth would make reviews and track pages fragile.
- Decision
- Create or reuse local `entities` when users publish reviews, then attach ratings, profile activity, and track pages to those records.
- Tradeoff
- Metadata can become slightly stale, but Kocteau gets durable IDs, fewer repeated external calls, and data it can query reliably.
Postgres and RLS over NoSQL
- Problem
- The product depends on relationships between users, reviews, entities, likes, comments, bookmarks, follows, and taste tags.
- Decision
- Use Supabase Postgres with relational modeling and RLS-aware access rules instead of a loose document model.
- Tradeoff
- The schema requires more upfront thinking, but joins, constraints, and policy-driven access fit the product better.
TanStack Query for server state
- Problem
- Reviews and social interactions change often, and manually coordinating fetches, cache, loading states, and optimistic updates gets messy.
- Decision
- Use TanStack Query for server-state synchronization, local cache, and interaction feedback.
- Tradeoff
- It adds dependency and bundle weight, but reduces custom state code and makes interactive surfaces feel faster.
Measurement
The case study should not invent traction. Instead, Kocteau can be evaluated through the signals that matter for this product category: activation, publishing, engagement, recommendation quality, and system health.
Observable signals
The next iteration should turn these product questions into dashboard queries or analytics events.
Activation
OTP to taste
How many users verify email, finish profile setup, and select preference tags.
Creation
First review
How quickly a new user searches a track and publishes their first rating or written take.
Engagement
Social actions
Likes, saves, comments, and follows show whether reviews create interaction beyond reading.
Discovery
Feed quality
Feed loads, clicks, follows, and review actions can reveal whether recommendations feel useful.
Result
Kocteau reached a functional MVP shape: users can authenticate, complete onboarding, search music through Deezer, publish reviews, browse social surfaces, and view public profiles and track pages. The strongest result is not a single feature, but a coherent loop that can now be tested with real behavior.
Learnings
- 01Recommendation quality starts before the algorithm. Onboarding, taste tags, empty states, and social defaults shape the first session.
- 02External APIs are inputs, not product foundations. Deezer can search music, but Kocteau needs its own stable entities.
- 03Server state deserves a dedicated model. Reviews, likes, comments, and saves feel better when cache and optimistic states are handled deliberately.
- 04Relational data fits social products. Reviews, follows, profiles, and entities benefit from constraints and explicit relationships.
- 05OTP auth looks simple but has hidden edge cases: email delay, spam folders, expired codes, redirects, and incomplete profiles.