About Honq

The problem I'm actually trying to solve. As Dean of the Honors College, I've been wrestling with encouraging and tracking beyond-the-classroom intellectual formation requirements. All the tools are the worst. At one extreme we could manage everything in a bunch of Excel sheets with shudder OneDrive. At the other extreme we could have our LMS add the open source microcredential platform that they bought and hid behind a white-glove-services paywall.

I built Honq because I needed a better answer to a question I ask all the time: did a student actually do the work, and can they show me? Other questions came up. Can we do it without asking students to spend more time in an LMS that was never designed for this? Could the tracking itself be fun?

What Honq is. Honq is a simple game that plays off the natural competitive nature of Honors College students. It prioritizes the embodied on-campus experience, and pays homage to long-running Honors College inside jokes about the aggressive Canada geese that confront us on the way to class.

A student scans a QR code at a colloquium or campus event to earn a badge on the spot, or has an advisor confirm work like research and publications, then stacks those badges into tiered credentials and climbs a cohort leaderboard.

I designed it so it never becomes an official institutional record: the student holds it, a human advisor verifies it in person, and the institution maintains nothing. That one choice keeps it cheap to run and light on IT, which is exactly why something like this hasn't existed for us already.

How I built it. This was my first hackathon and my first time with Claude Code, so I worked across two roles. With one, I did the thinking: shaping the concept, pressure-testing it against real constraints, and writing the specs and prompts (I also drew the goose). The other, Claude Code, did the building, turning those specs into a single self-contained web app. I came to learn the tooling as much as to ship the artifact, and I did both.

What I learned, and the hardest part. The hardest part was never the code, it was deciding the scope of the problem. My instinct was to build the whole system, the full record, every edge case. The discipline I had to learn was the opposite: cut to the smallest thing that tells a true story in five minutes, and let the idea carry the rest. Naming my own problem precisely turned out to be the most valuable action, and the result is a tool that could actually be put into production and solve a real challenge in an interesting way.

Built With

Share this project:

Updates