Hackathons with Cuyo Connect: what we built so teams can form, submit and win

Why a hackathon

Cuyo Connect is a software community from the Cuyo region of Argentina that organizes meetups, talks and hackathons so the people building technology in the region can meet and work together. In 2026 we joined as a technology ally and supported two hackathons in Mendoza: one in August, hosted at the Polo TIC, and another in October.

A hackathon is the most demanding event there is for a platform like ours, for a simple reason: networking isn't an extra, it's the competition. Whoever doesn't find a team in the first hour doesn't take part. Whoever submits late is out. And if the jury doesn't see every project, the winner is whoever had the table closest to the door.

So the agenda and the directory weren't enough. We built three new pieces, one for each stage of a hackathon.

Stage 1: forming the team

The first hour of a hackathon is usually chaos: people with an idea looking for someone to code it, developers looking for an idea, designers nobody knows are in the room.

The team board brings order to that. Whoever has a project posts it with the roles they're missing: backend, design, data, business. Others join by taking an open role. Every team has a real size limit, from two to six people, and the system doesn't let it overflow.

Tapping a member opens their profile and a private message. The person who proposed the project gets a notification as soon as someone joins. And the organizers see something that used to be invisible: the list of people who still have no team, so they can bring them into one before they leave. The room's screen projects the board with titles and open spots, without names.

Stage 2: submitting the project

When time runs out, each team writes a single submission: what problem it solves, the repository link, the demo link and what they built it with. Any member can edit it, from their phone.

Two design decisions matter here:

• Saving a draft requires nothing; submitting does. For a submission to count it needs the summary and at least one link. That way nobody loses work by rushing, and the jury doesn't receive empty projects.
• The organizer sets the deadline, and it holds. When the time comes, submissions close on their own. Nobody has to stand at the door saying "no more changes".

The organizers can set challenges —for example, one per sponsor— and each team says which one it's competing in. The organizers see every submission in one place, assign each team its table for the presentations and export everything to a spreadsheet.

Stage 3: the jury, from the phone

Judging is where a hackathon is won or lost, and it's almost always handled with paper and a spreadsheet shared at the last minute.

In Circli, the organizers add each judge by name and send them a link. Judges don't need to create an account: the link is their credential, and it can be revoked without deleting the scores they've already given. The judge opens the link on their phone, sees the teams ordered by table, walks the room and scores with the criteria the organizers defined. If they score a team again, they correct their grade instead of adding it twice.

Meanwhile, the organizers see the live ranking and, above all, which tables no judge has visited yet. It's the failure that decides many hackathons and that nobody notices until the awards.

A podium without math traps

For the podium we use the ranking method used at Major League Hacking events: each judge picks their top three, which receive three, two and one points, and those points are added up. Ties are broken by the average score, not the sum.

The difference sounds technical, but it changes who wins. Adding up raw scores rewards the team seen by the most judges, not the best one; ranking by favourites limits that advantage, but doesn't remove it. That's why coverage matters as much as the criteria: the organizers see live which tables no judge has visited, and while coverage is uneven the podium can't be defended yet. The rule is that every team gets the same number of evaluations; ideally, every judge sees every team. The results screen doesn't show the podium while any team is still unjudged, so nobody celebrates too early, but that block can't tell whether coverage was even: the organizers take care of that by checking how many visits each table got.

What guided the design

1. At a hackathon, forming a team is the first competition. The role-based board invites people to look for what their team is missing instead of for whoever they already know.
2. A judge without an account is a judge who takes part. Asking a guest judge to register is the fastest way to get them scoring on paper. A link on the phone asks for nothing.
3. What you can't see, you can't fix. Knowing which tables still need a visit is worth more than the ranking itself.

Why it matters to us

Circli was born in Mendoza, and we believe the region's tech ecosystem grows when the people who build meet each other. Supporting Cuyo Connect and software communities is our way of giving back some of what we've received, and also the best way to test the product with demanding users.

If you run a hackathon, a bootcamp or a community event, discover Circli Events or see how Circli communities work.