An event is also a product
Project GRID changed how I think about events. A hackathon is not only a date, a theme, and a registration form. It is a product with users moving through uncertain states. Students need to understand the problem, know what is expected, find teammates or support, submit the right evidence, receive credible evaluation, and see a path after the final pitch. If any stage is vague, motivation leaks out of the system.
My CTO role therefore reaches beyond software. It includes challenge framing, submission mechanics, judging criteria, communications, outreach, digital surfaces, and the operational details that keep a program moving. Those parts cannot be designed independently. The website sets an expectation that the judging process must fulfil. The challenge brief affects the mentors needed. The submission format changes what judges can evaluate fairly.
Pressure needs structure
Students often benefit from real deadlines and public evaluation, but pressure without structure mostly creates confusion. Aurora used staged progression to make the next level concrete: move from an idea to a prototype, then communicate the work in a live finalist setting. Public program materials describe four tracks, a 200-team shortlist, and 20 finalists, while Devpost lists 264 participants. Those numbers matter less to me than the mechanism behind them.
The larger lesson is that credibility comes from visible rules and follow-through. Builders should know how work will be assessed. Judges need criteria that separate novelty, feasibility, design, execution, and impact. Partners need a clear role. Organizers need systems that survive last-minute changes. Designing all of that made program architecture feel much closer to product design than event management.