Inside the Netherlands’ Biggest Student AI Buildathon: What Actually Worked

Fifty-five days before EurHackNL, I wrote that I was excited and terrified. That was not launch copy.

Putting applications, partners, four challenge areas and two full days into one room is not difficult because of the schedule. It is difficult because a large AI event can easily become a spectacle: many tools, many promises, and very little that survives after everyone goes home.

The bet behind EurHackNL was simpler. Give students real problems, useful constraints and enough support to build. Then ask them to show what exists—not what might exist after another six months.

A big room, but a simple contract

EurHackNL took place at Erasmus University Rotterdam on 18–19 May 2026. It was organised with Erasmus Tech Community, Erasmus Artificial Intelligence Society, Elena Avramenko, the Miro Community Team and Francisco Terpolilli, with students joining from universities across the Netherlands and neighbouring countries.

We organised the work around four broad areas: AI and work, climate, healthcare and education. The subjects were deliberately bigger than any one tool. A model can generate an interface quickly. It cannot decide whether the problem deserves to be solved, who might be harmed, or what a useful outcome looks like.

That part still belongs to the people in the room.

Before the event, I kept returning to the same thought: technical background should not be the admission ticket to building. What mattered more was whether someone cared about the problem and had enough curiosity to keep moving when the first prompt failed.

Structure mattered more than inspiration

The strongest part of a buildathon is not the opening talk. It is the operating structure around the builders.

Four things made the format work:

• Real missions. Teams were not asked to “make something with AI.” They had a problem space and people who could challenge their assumptions.

• Mixed backgrounds. Business students, engineers, designers and first-time builders approached the same briefs from different angles.

• A visible deadline. The time limit forced teams to choose what the product needed to prove and leave everything else out.

• A working demo. Slides could support the story, but they could not replace the thing itself.

AI reduced the distance between an idea and a prototype. It did not remove the need for judgment. In fact, faster production made judgment more important: teams could explore more directions, but they also had to decide which direction deserved another hour.

What emerged from the room

The range of projects was the point.

One team built OnstageAI, a copilot designed to help presenters understand when an audience is lost. Another explored how cities could make local participation easier without turning loneliness into a surveillance category. TWIN by EventLabs looked at how people discover useful insights and connections during live events. Cortex explored generating and testing advertising ideas before money is committed to a campaign.

These were not finished companies, and calling them that would miss the value of the exercise. They were working arguments. Each team had taken a position on a problem and made it concrete enough for somebody else to question, test or improve.

That is a much better starting point than agreement around a document.

What I learned

A buildathon does not prove that building has become effortless. It proves that the old boundary between “technical” and “non-technical” is becoming less useful.

The people who moved fastest were not necessarily the people who knew the most syntax. They could frame a problem, make a decision with incomplete information, ask for help and discard an idea that was not working.

The tools created agency. The room made that agency social.

That second part matters. Building alone can feel like constantly doing something for the first time. Building next to other people makes the uncertainty visible and normal. You see that everybody gets stuck. You also see how differently people recover.

What I would change next time

The next version should spend even less time explaining tools and more time improving the conditions around the work:

• Make team formation easier before the clock starts.

• Give mission partners a sharper way to explain the problem without prescribing the solution.

• Route mentors to teams based on the decision they are stuck on, not only the technology they are using.

• Create a clearer path for promising projects to continue after the final demo.

A good buildathon ends with working prototypes. A great one also leaves people with collaborators, confidence and a next move.

Hackathon or buildathon?

The name matters less than the contract with the room.

“Hackathon” describes a familiar time-boxed format. “Buildathon” places more emphasis on who gets to participate and what they leave with. We used buildathon because the intention was not to reward technical performance for its own sake. It was to help more people turn a problem they cared about into something other people could experience.

For me, that is the shift: from talking about access to giving people agency.

The public event record is available on Luma, and participant work continues in the posts linked above.

If you are trying to create this kind of movement inside a team or organisation, see how we run AI workshops and buildathons.