GalaGate

Problem

The original tools solved immediate event needs but are split across modules and older duplicate repositories. The backend still uses hardcoded sample data, which makes the product look smaller than the real workflow it represents.

Solution

Consolidate check-in, lottery eligibility, winner selection, and operator workflows into one event operations system. The public case study explains the real product shape while the codebase is rebuilt around persistence and admin controls.

Architecture

• CheckIn is a Next.js/TypeScript interface for attendee-facing check-in and event status flows.
• Lottery is a Nuxt/Vue interface with animated draw views and sponsor/event visuals.
• Backend is a Flask API currently coordinating check-in and lottery data, planned to move from hardcoded records to persistent storage.
• Docker Compose provides the foundation for running the multi-service system locally.

Engineering Decisions

• Keep CheckIn and Lottery as separate user surfaces because operators and attendees need different flows.
• Preserve the event-specific visual experience while moving data handling into a real backend.
• Design the rebuild around import/export and admin operations rather than only the public animation.
• Use the project to show non-technical stakeholder delivery and real event constraints.

Outcomes

• Supported event operations across four large gala-style events serving 1,400+ guests.
• Connected to sponsorship and advertising operations that generated $2K+ in revenue.
• Good proof of frontend breadth, Dockerized project organization, and operator workflow thinking.
• Currently marked In Rebuild until persistence and admin workflows are added.

Next Steps

• Replace hardcoded user data with SQLite or PostgreSQL persistence.
• Add Event, Attendee, CheckInRecord, LotteryEntry, and Winner entities.
• Build an admin flow for attendee import, check-in monitoring, lottery eligibility, and winner export.
• Update Docker Compose and README so a reviewer can run the full system locally.