The MIT&CIC&UPC Hackathon is an annual event organized by the MIT Edgerton Center in collaboration with UPC, where +240 HS students across three faculties ideate, design, and then build a project. In this blog post, I’ll go over the entire organization of a hackathon from the ground up—from documents used by the Edgerton Center to conduct design reviews to scheduling and ideating.

This is the ideal case scenario, and there are many things I outline in this document that we currently do not do. Part of my reason for writing this post is to create a better organizational structure for the future.

Additionally, I want to highlight Christian Cardozo and Aleksandra Kaminska for their amazing job during this last hackathon. As I’ll discuss below, this was a complicated hackathon in terms of experience and time, and I believe they were able to pull off the impossible.

Structure of a hackathon

The hackathon has five main parts:

Icebreakers

During Icebreakers, the goal is for students to break the dynamic of school and try to get them out of their comfort zone. We have done several activities in the past, including building tetrahedrons, bingo, rapid ideation, etc. However, I will go more in-depth into this topic in another post, as there are many lessons to be learned in this section alone. TL;DR: you need to break the kids’ expectations and make them talk to people outside their school. Activities within this section should encourage the sharing of ideas and experiences. In the past, we have used Bingo, the Marshmallow challenge, the telegraph, tetrahedrons, etc.

Ideation

In this section, students must come up with ideas and discuss them with their peers. It is critically important that they do not join based on friendships or schools in this part, as we want to avoid groups being formed by friends rather than by the idea. During this part, we want students to see all ideas and learn about what is being thought of across the room. We usually start by asking groups to form ideas with people around them. Then, we form categories based on their ideas, and they go to discuss these ideas within those categories. After this, we ask them to visit a different category to see other ideas.

Project Selection

After Ideation, students must join together into groups of 4 to 6 people, which cannot be formed by schools or friendships. Teachers are critical in this step as they know the students and we don’t. They have to upload a form containing the name of the group, their names, and a brief explanation and sketch of their project. This helps mentors organize them into common topics and assign them a mentor.

Project Building

This is the longest section of the hackathon by far, letting students build their projects. However, this section is actually divided into three parts:

Cardboard Prototype

First, we give students cardboard and ask them to build a prototype that either looks like or works like their project. This is to ensure: 1. The viability of the project; 2. The dimensions and inner workings of the project; 3. That the group actually cares about the project itself. 99% of teams fail because they don’t feel passionate about their project, and this can be seen early on.

Design Reviews

After the cardboard prototype, groups undergo a design review by an experienced mentor. This serves the purpose of better understanding the project, making sure students know what their project is and will look like, and ensuring that materials make sense and the approach could work. One of my favorite questions to ask here is: “As a user of your product, how does it feel to use it? Or what would it look like to use it?” This question makes them think about all the details they want their project to incorporate.

Minimum Viable Product (MVP)

After design reviews, we give groups a materials sheet and ask them to build a Minimum Viable Product or MVP. This serves to set a goal and some limits on what will and won’t happen at the end of the hackathon. Some projects may have a huge cardboard car while others may only have some electronics, but setting these boundaries is helpful, as students stop thinking about every single detail and just work towards a working prototype.

Presentations and Closure

By the end of day three, we have a project fair where parents come to see their kids’ projects. Students prepare slides and show their project working (or not) to their peers, teachers, and family members. After the fair, everyone goes to the auditorium where we have a roundtable with some students, teachers, and mentors, and we distribute diplomas to the students.

The 2026 Hackathon

This year’s hackathon was not the best we have ever done. I see several failures in both organization and execution that made the hackathon worse for everyone. Students do not realize these things because they are hidden, but we have observed several details that show a less-than-ideal hackathon.

Also, I must remind the reader that this article is intended to further improve the hackathon. Everything I discuss here should not be taken as criticism, but as a list of possible improvements.

Groups by Coalitions

One of the main problems encountered during the hackathon was that sixteen out of eighteen groups (16/18) were formed by coalitions of schools (i.e., 3 students from school A and 3 students from school B). We made it clear during ideation that they couldn’t form groups by schools—that they had to mix—but students resisted being alone. This created coalitions of schools, as most groups were formed mainly by the joining of two schools. This may look “good enough,” but it shows that students were not joining by ideas, but were simply evading the “no single-school team” rule. This could be due to an issue during icebreakers and ideation, where students did not mix properly and tended to stay close to their friends.

Lack of Communication

The main issue encountered during the 2026 Hackathon was communication, or the lack thereof. Schools, mentors, teachers, and students had complaints about a lack of a clear messaging and communication system, resulting in conflicting information that complicated the execution of the hackathon. For future years, a clear communication system must be created, including documents outlining everything that a school, mentor, teacher, and student should know before, during, and after the hackathon. The most critical part of organization and team management is communication—not only from top to bottom but horizontally within the organizational structure.

Mentor Inexperience

In Terrassa, out of 16 mentors, only four, including myself, had taken part in a hackathon before. This ratio is not ideal. Most mentors had very little knowledge of how to do their job or what to expect, making this hackathon feel a lot more like an actual school than it should have been. A ratio of 1:1 should be the minimum for a hackathon; last year we had seven new mentors with 11 experienced mentors, a ratio of 2:3, which is fairly balanced.

The table above shows an organizational issue with the distribution of mentors across hackathons. If someone had computed these numbers before the hackathon, we would have seen issues in 2026T before they happened.