Gyeonggi Changgo was a long-running youth AI hackathon program from May 31 through October 18, 2025. It began with twenty-two teams and about eighty students; ten teams finished with demo booths and pitches.
Across nearly five months, Working Backwards was not a one-time ideation exercise. It became an operating language that carried previous decisions and next experiments across changing teams and mentors.
Allow different output while sharing review questions
Projects included an object-detection glove, structural crack detection, and expiration management with recipe recommendations. Requiring the same interface or model would have made teams optimize for submission format rather than users.
Every topic instead answered the same questions:
- who experiences the problem first;
- which workaround do they use now;
- which one change will this phase test;
- what is intentionally outside scope until the next review.
The glove team needed to explain when and at what distance a user received an alert, not only how many objects the model recognized. The crack-detection team needed to explain who reviewed a risk candidate and which action followed. Deliverables differed while product decisions remained comparable.
Connect every program activity to the next decision
Training, mentoring, talks, and company visits can become disconnected experiences. Each activity therefore ended with one sentence for the next meeting:
- after training: a customer problem to check;
- after mentoring: scope to reduce or validate this week;
- after a talk or visit: an architecture or operating assumption to revisit;
- after a midpoint presentation: a hypothesis to keep or discard.
The record became a handoff when members changed or schedules slipped. Mentor advice also changed a sentence in the customer promise rather than remaining as “add another feature.”
Review uncertainty rather than polish at the midpoint
Midpoint reviews easily score UI and model completeness. At that stage, unverified assumptions were more informative.
Teams recorded whether required data existed, whether users had a path to challenge a result, whether high-risk decisions were being automated, and whether hardware or external APIs would work outside the demo.
An unanswered question became the next experiment rather than a penalty. Even under schedule pressure, teams could reduce the uncertainty most directly connected to the customer promise.
Complete the delivery path instead of adding final features
As the final demo approached, login, analytics, screens, and model features became tempting. Review returned to whether input, error handling, supporting evidence, and the customer’s next action formed one complete path.
If the core change remained visible without a feature, it was deferred. Teams strengthened the boundary between sample and real data, handling of wrong predictions, and explanation of results.
Ten booths and pitches were the visible output, but the program cannot be measured only by final team count. It also taught twenty-two teams at different speeds to preserve the reason behind a scope change and the evidence behind a next decision.
Gyeonggi Changgo showed Working Backwards operating as lightweight project governance rather than a single workshop canvas. A long program needs more than enthusiasm; it needs a record of what was learned and why the next decision follows.
Comments