How to do well at a hackathon as a first-year team

The biggest mistake first-time hackathon teams make is picking an idea that would take a professional team months to build. "An app that connects farmers to markets across East Africa" is a startup, not a hackathon project.

Instead, pick something small enough to demo in 24 hours:

• A form that collects specific data and displays it usefully
• A bot that answers questions from a single document
• A tool that automates one manual task for a specific user

The rule: if you cannot explain the core feature in one sentence, the idea is too big. Cut it down until you can.

Judges reward a working prototype that solves a small problem over a broken prototype that promises to solve a big one.

Spend the first hour on planning, then build. Do not plan for three hours. The clock is your enemy.

Agree on the stack. Use whatever your team already knows. A hackathon is not the time to learn a new framework. If everyone knows basic HTML and JavaScript, build with that. It is enough.

Assign roles. One person on frontend (what the user sees). One on backend or data (where things are stored and processed). One on the presentation and demo prep. If you have more people, split frontend or add a research and testing role.

Set a mid-point check. Halfway through the build time, stop and integrate. Make sure the pieces connect. If something is not working, simplify it. Cut the feature, not the deadline.

The team that ships a complete simple project beats the team that has an impressive but broken complex one.

Judges see your project for two to five minutes. They do not read your code. They watch your demo and listen to your explanation. A mediocre project with a great demo often scores higher than a brilliant project with a confused presentation.

Spend the last two hours on the demo. Structure it like this:

• The problem (30 seconds): What problem are you solving? For whom? Make it concrete. "Students at this university waste two hours per week trying to find their lecture rooms" is better than "we wanted to build a campus app."
• The solution (60 seconds): Show the working prototype. Click through it live. If it might crash, record a backup video.
• How it works (30 seconds): Brief technical explanation. What did you build it with? One sentence on the architecture.
• What is next (30 seconds): If you had another week, what would you add? This shows you understand the product beyond the hackathon.

Practise the demo at least twice before presenting. Time it. If this is your first hackathon, knowing the demo format in advance gives you an edge.

Fresh perspective. You have not been conditioned to think in frameworks and patterns. Your ideas tend to be more creative and user-focused because you think like a user, not a developer.

Hunger. Experienced teams sometimes coast. First-year teams hustle because they have something to prove. That energy is visible to judges.

Willingness to ask for help. Hackathons have mentors walking around. First-years ask them questions. Senior teams often do not. The mentors are there to help. Use them.

Your technical skill may be lower, but hackathons reward execution and storytelling as much as code quality. Play to your strengths. See the communities cluster for finding hackathons to enter.