PoolCzar — Cue-Sports Tournament, Community & Commerce Platform

PoolCzar is a tournament, community, and commerce platform for local billiards leagues — a storefront for cues, chalk, cloth, and cases alongside member forums and the tournament infrastructure directors actually need to run an event, not just announce one. The hardest part wasn't any single feature; it was giving tournament directors a way to configure rules per event without every director maintaining their own divergent copy of a 13-game rulebook.

The frontend is a Next.js static export on S3 and CloudFront, backed by Python Lambdas behind an API Gateway HTTP API with a Cognito JWT authorizer — real admin/tournament-director/forum-moderator roles, not a single shared login. Forums (threads, posts, events, RSVPs) and the store (catalog, real Stripe checkout) each get their own DynamoDB single-table design, scoped so a Lambda group's IAM permissions only reach the table it actually needs.

The rule builder is the standout piece: 66 reusable rule definitions, each with its player-facing wording written once, composed into 13 per-game templates (8-ball, 9-ball, one pocket, snooker, and so on) as thin references rather than duplicated text. Composition is resolved in Python at read time — not pre-flattened into files or buried in Terraform — so a director can layer a preset like "Fast Event" over a template's defaults and keep customizing from there, with a handful of rules (like shot-clock extensions) only appearing once the rule they depend on is turned on. That keeps one rulebook per game as the source of truth across every venue running it, instead of 13 files quietly drifting apart.

Tradeoffs and lessons learned

• Composition over duplication. Keeping 66 reusable rule definitions and composing per-game rule sets at read time adds application logic, but avoids maintaining divergent copies of the same rule text across games and tournaments.
• Serverless keeps operations small, but distributes complexity. API Gateway, Lambda, Cognito, DynamoDB, S3, and CloudFront reduce server-management overhead, while requiring deliberate IAM boundaries, observability, and deployment discipline across several AWS services.
• Role separation was worth the added authorization work. Distinct admin, tournament-director, and forum-moderator roles create more implementation work than a shared privileged login, but better match the responsibilities of a real community/tournament platform.
• Build the domain model before adding features. The reusable rule model became more valuable than simply shipping 13 independent rulebooks; investing in the model made presets and tournament-specific customization possible without creating content drift.