A hackathon — a blend of "hack" and "marathon" — is an intense product-building competition that usually lasts 24–48 hours. Teams build a working prototype from scratch around a given problem or theme and present it to a jury when time runs out. Winners take home prizes, internship and job opportunities, investor connections or places in incubation programs.
In this guide we explain step by step how hackathons work, which criteria judges look at, and what you can do to ship a standout project in limited time.
What is a hackathon and who can take part?
Hackathons are organized by companies, universities, municipalities, foundations and communities. Some run fully online, some take place in person on a campus or at a technopark, and some are hybrid, with online development followed by an in-person final. Themes come from areas such as fintech, health, climate, smart cities and AI; company hackathons usually hand you one of the company's real business problems.
Contrary to a common misconception, hackathons aren't just for software developers. Most winning teams include a designer, a product manager, a business developer or a domain expert (for example, a medical student at a health hackathon). Eligibility varies by event: some are open only to university students, some to a certain age range, and some to everyone.
How does a hackathon work?
- Announcement and application: The event page sets out the theme, dates, eligibility and prizes. Most hackathons ask you to fill in a team or individual application form.
- Selection and team building: At events with limited places, applications are reviewed. Team-matching sessions may be held for individual applicants.
- Kick-off and problem statement: Problem sets, data sources, APIs you can use and the scoring criteria are announced.
- Development: Teams build their prototypes during the set time while mentors give technical and business feedback.
- Submission: Source code, a demo video and the presentation are uploaded by the deadline. Submission deadlines are rarely extended.
- Pitch and judging: Teams present their projects in 3–5 minute pitches, then answer the judges' questions.
What do judges look for?
Scoring criteria vary from event to event, but most juries look for answers to similar questions:
- Problem–solution fit: Are you solving a real and important problem? Does your solution respond to it directly?
- A working demo: However good the idea, a prototype that works live is always more convincing than a slide.
- Technical execution: Are the technologies well chosen? Have sponsor APIs or the provided datasets been used meaningfully?
- Innovation: How are you different from similar solutions? Judges watch dozens of projects in a day; you need to stand out.
- Impact and sustainability: Can the project live on after the hackathon? Who does it help, and at what scale?
- Presentation: Can the team explain the idea clearly, briefly and convincingly?
Preparing before the hackathon
- Read the rules: Can you use code written beforehand? Are open-source libraries allowed? How many people can be on a team? Breaking the rules can get you disqualified.
- Prepare a starter template: Trying out the project skeleton, authentication, database connection and deployment steps in advance saves your first hours — if the rules allow it.
- Set up accounts and keys early: Cloud accounts, API keys and access to sponsor platforms can leave you waiting for approval at the last minute.
- Research the field: If the theme is known, look into the problems, existing solutions and open data sources in that area beforehand.
- Plan the logistics: For in-person events, bring a charger, an extension cable, headphones and comfortable clothes; for online events, a reliable internet connection and a quiet place to work.
How to build a winning team
The ideal hackathon team usually has 3–4 people. Smaller teams can't keep up with the workload, while bigger teams struggle to coordinate. Agree on roles from the start:
- Developer(s): Own the front end and back end, or the model side. If you have two developers, split their areas of responsibility.
- Design / product: Manages the user flow, screen designs and scope, and keeps asking "will this feature show up in the demo?"
- Pitch / business: Researches the problem, prepares the business model and the pitch, and talks to users to gather evidence if needed.
You can also team up with people you've never met; many events run team-matching sessions. In that case, spend the first half hour getting to know each other's skills and dividing roles.
Planning your 48 hours
Time is what hackathon teams lose most often. Keeping the scope small and showing a finished product always beats a big idea left half done. A sample schedule:
| Time slot | Focus |
|---|---|
| First 2 hours | Pick the problem, write a one-sentence solution statement, set the scope and roles. |
| Hours 2–20 | Get the core flow working end to end (MVP). Leave the polish for later. |
| Hours 20–36 | Fill the gaps in your demo scenario, improve the design and fix bugs. |
| Last 12 hours | Stop adding features. Prepare the pitch, record a demo video and rehearse at least twice. |
Demo and pitch: the last 5 minutes are everything
Judges rarely read your code line by line; most of the time they only see the pitch and the demo. So think of the pitch as the moment you get paid back for the effort you put into building.
- Problem (30 sec): Explain who has which problem with a concrete example.
- Solution (30 sec): Introduce your product in one sentence.
- Live demo (2 min): Walk through a real user scenario from start to finish. Always prepare a backup demo video in case of internet or server problems.
- How we built it (30 sec): Briefly summarize the technical architecture and the data / APIs you used.
- Impact and next steps (30 sec): Who could the project reach as it grows, and what comes next?
Common mistakes
- Making the scope too broad and finishing no feature at all.
- Spending the first hours debating ideas and starting development late.
- Starting the pitch an hour before the end and never rehearsing.
- Relying only on the live environment for the demo, with no backup video.
- Not asking mentors for feedback. Mentors often know best what the judges will look at.
- Underestimating sleep deprivation: short sleep breaks significantly reduce errors in the final hours.
Hackathon checklist
- I've read the eligibility requirements, the rules and the scoring criteria.
- Roles on the team are clear.
- The development environment, accounts and API keys are ready.
- We have a one-sentence problem and solution statement.
- We've set our feature freeze time.
- We've recorded a backup demo video and rehearsed the pitch at least twice.
- We've checked the submission deadline and the files to submit.
If you're ready, the next step is finding the right event. You can browse hackathons open for applications sorted by deadline and filter them by category and location.
Ready? Now pick your competition
See competitions open for applications in a list sorted by deadline.