Afterlight
Recover a concert history without surrendering it
Ownership
Solo Designer & Developer
Team
Solo / small team
Primary proof
Web + iOS + Android
Overview
Afterlight is a local-first concert diary with a Recovery Desk for the history people already have. It turns ticket files, incoming shares, calendars, photos, Gmail receipts, Setlist.fm attendance, and listening history into reviewable clues on-device. A clue never becomes a claimed night until the person confirms it.
The Challenge
Concert memories are distributed across camera rolls, ticket receipts, calendar events, Wallet passes, files, setlists, and half-remembered nights. Those sources have very different confidence: a Spotify play is a hint, while a ticket and dated venue photo together are stronger evidence. The product problem was not merely importing data; it was reconciling ambiguous evidence without letting software invent attendance.
Constraints
- •The canonical diary and recovery queue must work on-device; optional connected services cannot become the source of truth.
- •Low-confidence evidence can suggest a night but can never auto-confirm attendance.
- •Calendar, photo, and email access must be permission-gated, purpose-limited, and reduced to concert fields rather than retained source content.
- •Solo build — every feature competes with finishing.
Decision Log
Problem
Each import source originally behaved like its own workflow, and some hints could move too close to diary creation.
Decision
Put every source behind one versioned candidate model with provenance, confidence, deduplication, dismissal, editing, and explicit confirmation.
Tradeoff
Every integration has to translate into the shared evidence vocabulary instead of taking a shortcut to the diary.
Impact
The app can add new recovery sources without weakening the trust boundary: evidence proposes, the person decides.
Problem
Music apps default to streaming-service aesthetics — gradients, glass, glow.
Decision
Authored a design system from gig poster modernism instead: Factory Records palette, Swiss type discipline, grain, true black.
Tradeoff
A strong aesthetic position will alienate some users.
Impact
The app feels like the objects it's about — posters, tickets, the printed ephemera of going out.
Problem
Spring animation invites spectacle.
Decision
Built a small motion grammar — a handful of springs used consistently, nothing animating from scale(0), nothing over 300ms.
Tradeoff
Restraint reads as less impressive in a screen recording.
Impact
Motion clarifies state instead of performing for the user.
Approach
1. One desk for scattered evidence
Shares, uploads, calendar scans, photo clusters, Gmail receipts, Setlist.fm attendance, and Spotify hints all land in the same Recovery Desk. Provenance survives merging, so a candidate can explain why it exists.
2. Confirmation is the write boundary
Recovery candidates remain separate from confirmed concerts. People can review, correct, dismiss, or complete them; only completion calls the existing local concert-creation path.
3. Native reach, local core
iOS and Android share targets, calendar and photo access, and native Gmail OAuth reach evidence where it already lives. The canonical diary and candidate queue stay on-device, while optional network lookups enrich rather than own the record.
4. Gig poster modernism
The interface borrows from the printed history of live music — FAC blue, true black, grain textures, and Swiss type discipline — with a restrained motion grammar used to clarify state.
Outcome
A shared recovery system now spans web and native entry points, with a signed iOS share extension, Android share configuration, explicit privacy disclosures, and regression coverage around evidence parsing and confirmation. The web Recovery Desk is deployed while the next native release remains in development.
Proof points
Web + iOS + Android
Platforms
User-confirmed only
Diary writes
On-device
Canonical data
Learnings
- →Import is a trust problem before it is a parsing problem; provenance and confirmation belong in the data model.
- →Local-first does not mean banning the network. It means connected services can enrich the product without owning its canonical record.
- →Native extensions fail in platform-specific ways, so simulator compilation is not enough; the share handoff itself needs end-to-end exercise.
Anti-Patterns Avoided
- ×Treating listening history, a photo cluster, or a ticket receipt as proof of attendance.
- ×Retaining Gmail message bodies or calendar content after extracting candidate fields.
- ×Making a hosted database the canonical source for a private concert diary.
Next Iterations
- →Complete Google restricted-scope verification before broad Gmail recovery access.
- →Ship the updated native targets after same-build physical-device verification.
- →Expand the versioned archive into a plain, durable export and restore workflow.
Get In Touch
If you want to talk about similar work, email me.
Contact is the simplest place to start.
Next project
Ch'lita