Chinat · September 5, 2026

The Corporate Hackathon Has Everything Except the One Thing It Needs

This week I took a call with two people whose corporate hackathon had everything except builders. A hardware sponsor sending engineers. Two university venues. Recruiters with open roles, a 36-hour format, and a previous winner that became a company, with the sponsor lined up as its first customer.

What they did not have was developers.

"That is probably where we lack the most," one of them told me. "We have done all kinds of other sourcing." They had budget, partners, and a venue. They could not fill the room.

I have organized hackathons for about 1,000 people a year on campus and a few hundred more across the Bay Area, and I have sat on every side of the table: hacker, organizer, sponsor, mentor, judge. That call named the constraint. In a hackathon, money is not the scarce resource. Access to builders is.

Why a company like that wants a hackathon

They were blunt about the motive, and I respected it. The industry does not read as exciting to a 22-year-old who can code. It is heavy, physical, old. And yet it runs on software now, and it cannot hire the people who write it. So they run a hackathon, not mainly to get a product, but to get a weekend in which a hundred strong builders touch their problems and meet their engineers.

When I asked why corporates run these events, the answer broke into three buckets, and I think they are the right three:

1. Internal innovation. Your own engineers see how outsiders attack your problem in 36 hours. Mentors and judges learn as much as participants. It is upskilling disguised as a competition.
2. Recruiting and go-to-market. Recruiters in the room, roles on the table, and a live audition that no interview can match.
3. Brand. A weekend that makes an unsexy industry look like a frontier.

If you are a corporate reading this, be honest about which one you want. The event you design for recruiting is not the event you design for a product.

The IP structure worth copying

The part I want every builder to read carefully is how they handled IP. Developers own 100% of what they build. The sponsor keeps the right to commercialize it, and positions itself as the first customer if a team wants to keep going. They described it as the same arrangement a PhD student has with a research lab, and it is a long way from the "we own everything you touch" clause I have seen at other corporate events.

Their previous edition proved the model. The winning team did not just collect a prize. They spun out a company doing techno-economic analysis for the industry, with the sponsor as a warm first buyer. That is what a hackathon can be when the incentives are set up right: a deadline that hands a team its first customer.

Aim high, then let the room decide

They designed the problem statements for PhDs and postdocs, because the problems are genuinely hard. Then they watched who showed up: anyone who could code and use the equipment, with the sponsor's engineers running office hours to cover the domain gaps.

I think that is the correct order. Write the problem at the level of the problem. Then lower the barrier to entry with mentors, not by watering the problem down. The strongest undergrads will rise to it, and the ones who cannot still learn something they would never touch in a classroom.

How they found me

They found me through a ranked list and my AI twin, not through a referral. They found a list of hackers, clicked into my profile, landed on the AI twin I built of myself, and started chatting with it. By the time they emailed, my agent had already answered half their questions.

That is the new funnel. Being findable is a list. Being worth a call is a body of work the person can talk to before they talk to you.

What I told them

I told them the truth: judging and mentoring I am glad to do, because the event is good for builders. Recruiting builders is the hours-heavy bottleneck, and the one thing they lack, so that is what deserves the budget.

If you run events for a company, look at where your bottleneck really is. It is almost never the thing you have been spending on. If you build, look at the IP clause before you look at the prize. The prize is a weekend. The clause decides whether the weekend turns into a company.

← Back to all posts