Development phase · 2026
Case study
Waxlist
An unpublished record-collecting app that matches Spotify albums to Discogs releases and keeps collection, shelf and buying information in one workspace.
- Shared record workspace
- Discogs match confidence
- Missing shipping handling
- Spotify and Discogs integration
Context
Waxlist is a personal vinyl-collection app for Discogs users. It covers record-shop checks, shelf locations, collection maintenance and buying research.
It starts with Spotify albums, finds likely Discogs releases and keeps the result in a private workspace. A collector can check whether a record is owned, wanted, duplicated or shelved before buying it.
Ownership
Product design and full-stack engineering
Next.js · TypeScript · Postgres · Drizzle · Spotify API · Discogs API
- Defined the product model and designed the app shell, record inspector and responsive workflows.
- Built server-side Spotify OAuth, Discogs integration, deterministic matching, caching, rate-limit handling and Postgres storage.
- Implemented collection import, collection and Digging search, shelf locations, collection health, smart wants and buying checks.
Ownership boundaries
Waxlist is an unpublished personal product. There is no public release, live service or production user base.
The screenshots use invented records in an isolated local session. They contain no real account, collection, credential or provider data.
Constraints
- Spotify and Discogs tokens must stay on the server. Rate limits and provider failures still need clear states in the interface.
- Albums, masters, exact releases, reissues and listings are different records, so a weak match cannot be shown as fact.
- Discogs does not always return shipping or final checkout totals. Missing costs must remain unknown.
- The app needs to support long desktop sessions and quick phone checks in record shops, including cached collection search on a poor connection.
Decisions
Keep record context between tools.
- Approach
- Dashboard, Collection, Wantlist, Digging, Shelf and Health sit inside one app shell. The shell owns the selected record and passes it to one inspector.
- Trade-off
- A shared selection model needs more state coordination than separate pages. It keeps the active record available while the collector changes tools.
- Why
- A collector can move from search to shelf location or buying notes without finding the same record again.
Match the record before ranking price.
- Approach
- Spotify albums become deduplicated Discogs searches. Artist, title and vinyl format produce a confidence score, and only scores of 75 or higher become reliable matches. Weaker candidates stay available for review.
- Trade-off
- A confidence threshold produces fewer automatic recommendations. It also stops a cheap but incorrect release from looking convincing.
- Why
- Price and availability can sort a strong match. They cannot repair a weak identity match.
Do not invent missing costs.
- Approach
- Item price, shipping, source, checked time and freshness are stored separately. Unknown shipping blocks the total. Seller Scout groups only observed listings for the exact wanted release, and Discogs remains responsible for final tax and checkout values.
- Trade-off
- Withholding a delivered total and limiting Seller Scout to exact wanted releases returns less information. The alternative would be a guess.
- Why
- The interface can compare the values Discogs returned without filling gaps with invented numbers.
Proof
AppShell owns one selected-record model across Collection, Wantlist, Digging, Shelf and Health. The matcher uses a 75-point reliable threshold and keeps weaker candidates in a review path. Wishlist and Seller Scout tests confirm that unknown shipping is never treated as zero. The screenshots use invented records in an isolated local session with no live credentials or private collection data.
The clip opens on Collection with an invented Blue Train record selected in the inspector. It moves to a Digging search with owned and shelf information, then finishes on the collection-health audit. No real account, collection or provider data appears.
Text description
Silent visual walkthrough. An isolated Waxlist Collection view loads three invented records and selects Blue Train in the shared inspector. The view changes to Digging, searches for Blue Train, and shows owned, duplicate, shelf, and price-evidence signals. It finishes on Health with synthetic collection findings. No speech or audio is present.
Outcomes
- Built an authenticated workspace with navigation, global search, one record inspector and clear sync and empty states.
- Added Discogs collection import, cached Collection and Digging search, shelf locations, collection-health checks and non-destructive record actions.
- Added deterministic Spotify-to-Discogs matching, confidence scores, weak-match review, caching, throttling and provider-error states.
- Added Seller Scout for exact wanted releases and blocked delivered totals when shipping is missing.
Reflection
Uncertainty belongs in the data model. Match confidence, import state, stale prices, missing shelf locations and unknown shipping are all shown directly.
A public release still needs deployment configuration, production migrations and browser testing with real Spotify and Discogs accounts. That is why this case study has no live-product or source link.