A concert history, backed by a real database
Independent Product
A concert-history dashboard backed by a real database, heatmaps, tour maps, and a memory wall.
A concert history, backed by a real database
Every concert I've been to lives as a row in a Postgres database, artist, venue, date, who I went with. Admit One turns that history into a personal, Spotify-Wrapped-style retrospective: total shows, a shows-per-year chart, home-turf venue rankings, a genre leaderboard, a "dive bar → stadium" venue-size breakdown, a GitHub-style monthly heatmap, streaks, a setlist deep-dive, a photo memory wall, and an interactive tour map with a "relive the tour" route replay. I designed and built the whole thing, backend included.
Admit One started with a Google Sheet as its database, read live via the Google Visualization API to avoid running a server. That worked until the dataset and the feature list both outgrew it: no real schema, no real auth beyond a shared passphrase, and no good way to enforce data integrity as more shows, venues, and photos piled in. The Sheet has since been retired for Postgres on Supabase, with Vercel serverless functions as the API layer in front of it, and real sign-in (Google OAuth or a magic link) replacing the old passphrase-protected write flow.
The spreadsheet retired for Postgres, with a real API in between
The point isn't logging tickets, it's looking back. Shows-per-year and monthly-heatmap views surface patterns I'd never have noticed manually (which months I actually go out, which years were dry spells), and the venue-size breakdown turns "dive bar to stadium" into an actual chart instead of a vague memory.
A GitHub-style heatmap of every show attended
Setlist.fm, Last.fm genre data, Deezer artist photos, and Google Photos album previews all get pulled in through the same Vercel serverless functions that handle reads and writes against Postgres, one lightweight API layer doing double duty instead of standing up separate services for each source.
Four external sources, one API layer
The service worker deliberately never force-activates a new version, instead of silently reloading mid-scroll, it surfaces an "Encore Available" prompt so I choose when to update, avoiding lost state in the middle of browsing my own concert history.
"Encore Available" instead of a silent reload
No framework, no build step on the frontend, plain HTML/CSS/JS shipped as an installable PWA with a hand-written service worker, backed by Vercel serverless functions talking to Supabase Postgres. It's deployed on Vercel with a small CI workflow that bumps the service-worker cache hash on every push, and it's under active, ongoing development.