Case study
Fete Finder Operations
Work on the system behind the public programme: data management, publishing, backups, placements, analytics, and the launch controls that kept a cultural product dependable across 3,000+ registrations and 50,000+ unique visitors.
Tension
The product problem beneath the work.
The public experience could only feel calm if the operating model behind it was calm too. Event data changed, partners needed placements, hosts submitted updates, and launch traffic made manual recovery paths too risky to leave implicit.
Threads
Three operational systems beneath the public surface.
Owned
What I was responsible for, and what it changed.
| Thread | Work | Signal |
|---|---|---|
| Runtime data | Built a Postgres-backed event store, CSV import/export paths, backups, local fallback, validation, and revalidation controls. | The public site could keep serving useful event data even when the live store needed recovery or republishing. |
| Admin workflow | Built admin surfaces for content editing, operations, placements, insights, submissions moderation, runtime health, and rollback. | The launch workflow became a set of explicit operational moves rather than a bundle of manual interventions. |
| Partner signal | Built spotlight/promoted scheduling, partner activation queues, tokenized partner stats, engagement tracking, and reporting exports. | Commercial placements could be operated with traceable performance without breaking the public discovery experience. |
Mechanism
The technical layers behind those responsibilities.
| Layer | Detail |
|---|---|
| Source chain | Managed Postgres event store first, latest backup second, bundled CSV fallback last. |
| Data quality | Event assembly, date normalization, event keys, field transformers, quality checks, and warning surfaces. |
| Publishing | Event sheet editor, manual backups, save-and-revalidate flow, live runtime snapshot, and restore path. |
| Security | Admin sessions, route-level authentication, cron secrets, deploy revalidation tokens, and rate-limit storage. |
| Placements | Featured schedule, promoted schedule, Stripe activation ingestion, partner queues, and tokenized reporting pages. |
| Analytics | Event engagement, discovery analytics, calendar-save signal, outbound clicks, partner rates, and CSV export. |
Shape
How the work moved from edits to launch confidence.
- Event data enters through admin, import, or submission paths.
- Assembly and validation turn messy rows into stable public event objects.
- Operators back up, publish, revalidate, and inspect runtime status.
- Placements are scheduled and fulfilled without becoming hard-coded editorial state.
- Engagement and partner reports turn launch activity into a measurable signal.
Reflection
What the project clarified about launch systems.
The important work was making the launch less dependent on a single perfect path. A public campaign can absorb change when data, publishing, recovery, placements, and reporting each have explicit contracts.