A hackathon is an interesting thing. In principle, it’s great. Everyone builds software quickly, it gets judged, usually on feasibility, impact, technical level, etc., and then someone wins a prize and sometimes pursues that project further. Makes sense.
Going into the Berkeley AI Hackathon 2026 this year, Hao and I had a pretty good track record. 1st at the Reddit Games hackathon, 2nd at the USC ISI hackathon. We thought we knew what a good project meant. Going in, our idea was simple, but we thought it was cool.
Physics real time visualization. You record a video -> we use Claude vision to pick keyframes -> we do arithmetic to figure out relative velocities of the primary object in the video -> user gets a cool visual of the video but in a physics x-ray. Think a tab for Newton diagrams, one for momentum, one for energy, etc. The pitch was going to be something along the lines of “Gizmos for Physics” from an education standpoint.
The day before the hackathon, we stumbled upon an idea we thought was really cool, but tough to build. It came from the idea that in big tech companies, it’s very common for engineers to be separated into teams. Take Amazon. I’m sure there’s a payment and a cloud and devops and every team in existence, but all of them are building on Amazon infrastructure. The idea is based on the fact that those developers are very likely to work on the same problems over and over again, but there’s no way currently to fix this. Our suggestion: a permissioned knowledge sharing network for agents. I’m working on a problem -> my agent asks other agents in my company/team if they’ve worked on the project before -> that agent raises its hand and shares its info.
At the core, this idea seems much more useful and practical, and so we went with it, and I’d say we built it pretty well. Feel free to read more about the technical specs here. Little did I know, we were so very wrong.
There are three main problems with building something like this at a hackathon:
- It’s hard technically to do well.
- It’s a dev tool, the most crowded category in any hackathon.
- There’s no cool “aha” moment that we can show.
At this hackathon, the format was that 3 projects from our category made it to the finals. In our category, the three teams that made it were:
- A generic AI agent red-teaming tool.
- A tool that takes pictures and turns them into 3D renders.
- A spin on the Playwright tool for Claude.
We felt our project was more intricate and interesting than everything that made it to the finals. The thing is, that’s not what matters at a hackathon. I’d say out of the 3 problems I mentioned, the biggest to consider is the third one, the aha moment. The thing with these hackathons, and hackathons in general, is you get maybe 3 to 5 minutes to present your project. The person that’s watching your demo has just seen 10 other projects and wants to move on. You’ve gotta grab their attention and make them remember you. Although we had the coolest tech and a cool project, it was at the core an integration into Claude Code/Desktop that made 1 command work. Our UI was a simple visualization of agents talking to each other. No matter the practicality, that’s not as appealing to a judge as a 3D render being made in front of them.
What’s fascinating about this idea is that we did it so well at our first hackathon, the USC one I mentioned. We built reTeach, which was a simple tool that made students take a quiz and based on the prerequisites they were missing it would map them catch-up assignments. It’s simple, but the judges immediately get it. The value is obvious. Although Beacon has value in its own way, it’s not the easiest thing to make that obvious in 3 minutes. Our first judge liked our demo, but it makes sense why the other projects advanced and we didn’t. Later on we got judged by another judge that was just lurking after the real judging period, who we got to talk to for about 15 minutes. In that time span, he was really able to understand our project and actually offered to support us in the future. That guy was Kenny Zhang (3x YC). The thing is, that proves the point of quick attention further. At a hackathon you have to make something that makes sense immediately.
This lesson goes much further than hackathons. It’s applicable to selling any software ever. It doesn’t matter if you are getting judged by a tech founder or selling to a school admin, you have to make value obvious. Products whose value is hidden in a maze of jargon really have no value at all to others. So although yes, we lost the hackathon, I see it as a huge win.
First of all, we built some really cool technical software I’m proud of and I can talk about in the future, but most of all, we learned an important lesson the hard way. Make your value obvious. Make sure the person you are talking to understands exactly why they need what you have. Make sure the person who’s listening understands what they are being sold.
But I can’t end on a loss of course, so we’ll see how CalHacks goes in October :).