Community Booking App

Draft. Site under construction. Case study describes a real shipped project, written generically.

What the business needed

A community of event organizers needed a single coordinated way to publish listings, sell tickets, and track the operational pieces of running recurring events. Their existing setup was a patchwork: third-party ticketing for some events, spreadsheets for others, email threads bridging the gaps. Anyone running an event was reinventing the workflow each time. None of it was designed around how the community actually operates.

The brief was simple. One place. Events listed, tickets sold, manifests tracked — without anyone copying data between tools.

What I built

A single full-stack progressive web app covering both the public-facing experience and the back-office workflow. Visitors browse events, buy tickets, and receive confirmations. Organizers see live capacity, attendee lists, and the operational state of every event they are responsible for. Mobile-first, installable on any device, no app store.

The system is designed to be operated by a small team — including by me. I built it, deployed it, and run it.

Stack / Approach

TypeScript end to end. PostgreSQL for the core data model. Server-rendered with progressive enhancement, so it works without JavaScript and gets richer when JavaScript is available. PWA shell for offline-tolerant use in the field. Boring infrastructure on purpose — a solo operator cannot afford a system that needs constant attention.

Every decision was made with the assumption that the on-call person is me.

Outcome / What it taught me

In production. Operational since launch. I built it. I host it. It runs.

The gap between “shipped” and “still running well a year later” is most of the value. Code is the easy part. Choosing infrastructure that does not surprise you, writing logs that are readable at 2am, and keeping ongoing maintenance cheap enough to be worth doing — that is the work most engagements never plan for.