Band Boosters Platform

The Band Boosters Platform is a full system I built for running a high-school band booster program — in production for the Glacier Peak High School Band Boosters in Snohomish, WA, a 501(c)(3) supporting 183 student musicians across six ensembles. The public site leads with the program: a hero that states what the boosters do and the numbers behind it (student count, ensembles, 4,200+ volunteer hours a season), split entry points that send families to either a Students or a Parents track, and a live "help needed soon" board surfacing the next volunteer openings — Band Camp, football-game concessions — each with its clearance requirements noted. Below that runs the events calendar with per-event photos and registration.

Behind the public pages sit a family portal (balances, orders, forms, volunteer hours, varsity letter points, directory) and a real back office reachable from a left icon rail: an append-only finance ledger, a form builder with e-signatures, roster and uniform/instrument inventory with barcode checkout, trip management with an offline mode for chaperones on a bus with no signal, and Robert's-Rules governance — agendas, minutes, motions, votes, and coordinator handoff.

I built it because the program ran on a WordPress site plus six disconnected tools — Jotform, Zeffy, Google Sheets, Calendar, Drive, Streamline, and email — that shared no data, so "call time moved to 4:30" reached some families and not others. The harder problem underneath is turnover: a volunteer board rebuilds its own institutional knowledge every year, and no existing product solves that handoff, so governance, continuity, and role-based knowledge are first-class features here rather than afterthoughts. Zeffy stays on purpose — it's zero-fee for nonprofits — and the platform is the system of record but never holds funds.

It's Next.js 16 App Router on Firebase — Firestore, Auth with custom claims, Cloud Functions for fan-out, scheduled jobs, and annual season rollover — shipped as a mobile-first PWA with push, since most families use it from a phone in a parking lot. Seasons were stamped on entities from schema v1 so rollover needed no migration later. The piece I'm most pleased with is the volunteer signup engine: it serializes cap and waitlist ordering through a single per-shift counter document, so N parallel signups against a cap-K shift resolve to exactly K confirmed and N−K waitlisted, proven by an emulator-gated concurrency test. Access control is a scoped custom-role system over a 2,486-line Firestore rules file with its own test suite — a role can grant write on one specific page or event rather than a whole section. It's built out and running on an alpha host, pending the cutover window. Built Jun–Jul 2026.