Luma Data Pipeline
Automated event analytics across 11 events and 2,100+ guests, replacing manual spreadsheet tracking with a CLI-driven SQLite pipeline.
Context
After running 10+ AI Build Club events, I was tracking attendance, feedback, and guest data across disconnected spreadsheets and Luma exports. Every time I needed a metric for a partnership pitch or grant application, I spent hours pulling numbers manually. The data existed but was scattered and stale the moment I exported it.
My Role
I designed the schema, built the CLI, wrote the import pipeline, and maintain it. This is a solo project I use daily to run AI Build Club operations.
Approach
I needed something that fit my workflow: a CLI tool I could run from the terminal, not a dashboard I'd forget to check. Key decisions:
- SQLite over Postgres — single-file database, no server to maintain, portable across machines.
- CLI over web UI — I live in the terminal. A web dashboard would have been an extra thing to maintain.
- Luma API as single source of truth — pull fresh data on demand rather than maintaining manual imports.
How It Works
The pipeline pulls event and guest data from the Luma API, normalizes it into a relational schema (events, guests, feedback), and stores everything in SQLite. CLI commands expose queries for common operations: attendance by event, guest overlap, feedback aggregation, and export for reports.
$ luma sync --all
Syncing 11 events...
✓ 2,147 guests imported
✓ 847 unique attendees
✓ 156 feedback responses
$ luma stats --event "march-2026"
Approved: 89 | Showed: 52 | Show rate: 58%
New guests: 31 | Returning: 21 Results
The pipeline replaced a manual process that took half a day of spreadsheet work every time I needed numbers for a partnership pitch, grant application, or event retrospective. Now it takes one command.
What I Learned
Placeholder for reflections. What surprised you, what you'd do differently, what this project taught you about building tools for yourself vs. for others.