Mastermind · February 14, 2026
The Stanford hackathon changed what I thought I was building
Walking the TreeHacks floor reframed what I thought I was building. The hackers there aren't asking for a better submission tool. They're asking for the event layer to get out of their way.
I'd been running MentorMates for a while on the assumption that the product surface was the submission and review flow. Organizers post an event, teams submit projects, judges review them, winners get announced. That's the shape a lot of us inherit from the generation of platforms that came before us. The surface is a form and a leaderboard.
TreeHacks is a thousand participants and it makes that framing look small. Walking the floor, I had three kinds of conversations. Organizers told me the hardest part of running the event wasn't judging, it was logistics. Participants told me the hardest part of joining wasn't submitting, it was coordinating. Sponsors told me the hardest part of participating wasn't the platform, it was getting meaningful time with the builders they cared about. Nobody complained about submission forms. Everybody complained about coordination.
That's the product. The event layer is where the actual pain is, and nobody is building for it. Submission tooling is a piece of the event layer, but it's the easiest piece, which is why it's also the most crowded. The hard piece is the coordination infrastructure: how teams form, how mentors get matched, how judges get their assignments, how sponsors meet the participants they want to meet, how announcements propagate, how the schedule absorbs a room of eight hundred people doing eight hundred different things. That's a hackathon operating system, not a submission UI.
I said this to Xisen on the call and he pushed on the implication. If MentorMates is an operating system, it has to show up where the event happens, not where the judging happens. Which means the product has to run during the event, not just bracket it. The metric that matters is not how many projects submitted, it's how many organizer decisions the platform absorbed during the forty-eight hours the event was live.
That reframe changes the roadmap. Features that help an organizer coordinate in real time move up. Features that help teams coordinate with mentors in real time move up. Features that make a sponsor feel useful for a weekend instead of bored move up. The submission flow gets maintained but stops being the feature we lead with. The flagship demo shifts from showing a beautiful submission page to showing an organizer running a live event with less friction than they thought possible.
The other reframe that came out of TreeHacks was about the flagship we're planning in Hong Kong for July. I'd been treating the Hong Kong event as a marketing play with a product surface attached. After walking TreeHacks, the framing flipped. Hong Kong is the live test of whether MentorMates can actually be an operating system for an event at scale, and the marketing is the byproduct. A thousand participants in Hong Kong is the product moment. Everything that doesn't feed that moment is adjacent work.
Xisen's side mirrors this. He's narrowing Pulse down to a tight founder use case and cutting the surface area of the product to make the few things it does really sharp. That's the same discipline. Hong Kong is where we cut features. Hong Kong is where we commit to the product surface being the event, not the form. The weekend doesn't succeed because we announce it, it succeeds because an organizer running the event runs it better with us than without us.
The uncomfortable question that came up on the call, and I want to write it down because I don't have a clean answer yet: how much of the operating-system version of MentorMates can we actually ship by July? The honest answer is that we cannot ship all of it. So the exercise this week is figuring out which two or three pieces of the event layer are the ones that, if they work, make the organizer feel like MentorMates is load-bearing. Everything else is version-two.
The question I'm carrying out of this call: what is the smallest version of the event-layer operating system that an organizer will refuse to run without next time? If I can answer that question, the rest of the roadmap organizes itself. If I can't, I'm still building a submission form with ambition.
The check I'm making on myself: the TreeHacks writeup goes public this week, the Hong Kong plan gets written down with specific features, not vibes, and the next conversation with an ambassador network is framed around the event-layer pitch, not the submission pitch.