Ingestion
Extended streaming history arrives as years of JSON exports. The importer normalises tracks, resolves duplicates, keeps unknown URIs, and preserves the original timestamps so history stays auditable.
Product
Everything you have listened to, made legible.
SpotRecap is one system with four parts: an ingestion layer that never loses a play, a storage model built for history, an intelligence layer that explains itself, and a client designed for a phone.
271,712plays reconciled in the reference history
14tables, plus four materialised views
13question handlers behind the assistant
< 12 scold start, chat answer streamed
Figures as of 9 November 2026, measured against the reference history on the deployed service.
Architecture layers
Storage
PostgreSQL with vector indexing. Plays, tracks, artists, audio features and learned context live together, which is what makes cross-decade questions cheap to answer.
Intelligence
An intent router sends each question to one of thirteen handlers — statistics, comparisons, recaps, recommendations — and the answer streams back as it is computed.
Experience
The client is being built in Phase D as a progressive web app: installable, offline-tolerant, and laid out for a 380 px viewport before it is laid out for a desktop.
Enrichment
Audio features, cultural context and lyric signals are attached to tracks in batches, versioned so a re-run never silently changes a score.
Operations
Health endpoints, deploy verification and a cost ladder with a measured query budget — so running the thing stays predictable month to month.
In practice
What it feels like to use.
“Which artists did I discover in the year I moved, and who did I keep?”
- Ask in a sentence
No query language and no filter builder. The router picks the handler and returns a written answer with the supporting figures.
- Every claim is checkable
Answers reference the plays they were computed from, so a surprising number can be traced rather than trusted.
- It remembers
Durable notes about taste and prior questions are stored alongside the data, so the assistant does not start from zero each session.
- Nothing leaves your account
Listening history is personal data. It is stored single-tenant, never sold, and exportable in full.
Interface preview
How the interface is laid out.
Illustrative mockups of the two core surfaces — a year recap and the assistant. They show the layout and density the phone client is being built to, not a shipped screen.
2019 in listening
18,402
plays · 214 artists discovered · 41 kept
Which artists did I discover in 2019, and who am I still playing?
You added 214 new artists in 2019. 41 are still in rotation five years later.
Kept after 2019 41
Played once, never again 126
Reappeared in 2024 9
computed from 18,402 plays · 2019-01-01 → today
Under the hood
Engineering choices we can defend.
A short, honest summary of the architecture — enough to show how the system is put together, without publishing the parts that make it ours.
| Concern | Approach | Why |
|---|---|---|
| Storage | Relational core with vector indexes | History is relational; taste is geometric. Both belong in one place. |
| Model access | One abstraction over six providers, with an ordered fallback chain | A single vendor outage should degrade the assistant, not stop it. |
| Delivery | Containerised service, EU region, private database network | Data residency and a small blast radius. |
| Quality | Contract tests per route, a smoke test on every deployment | “Deployed” means verified, not uploaded. |
| Cost | Query budget per phase, with a cheaper equivalent proven before it is needed | Keep the service affordable enough to leave running. |
See it with your own history.
Private beta access opens in small batches. Bring an export and we will tell you what is in it.