To prepare for your first hackathon as a beginner, you do three things before the clock starts: pick one narrow problem instead of a broad theme, get your local dev environment running so you are not debugging setup at hour three, and rehearse a two-minute story about your idea. A hackathon is a timeboxed sprint, usually 24 to 48 hours, where a small team builds a working prototype against a published challenge and then demos it to judges. You never arrive with a finished product. You arrive with a scoped idea, a tested setup, a team that knows its roles, and a clear sentence explaining who the project helps and what it does.
Most first-timers underestimate the preparation and overestimate the coding. The smart ones arrive with a boring, reliable setup and spend their creative hours on the problem instead of on plumbing.
This guide walks through everything you need before you walk in, nine preparation steps in the order they actually happen, and the mistakes that quietly cost teams their demo. It takes about an hour to work through the checklist and another evening per step, so a first-timer can be genuinely ready in about two weeks.
Table of Contents
- What You Need
- Step-by-Step
- Common Mistakes
- Frequently Asked Questions
- Do I need coding experience for my first hackathon?
- What should I bring to a hackathon for the first time?
- Can you use ChatGPT or an AI coding assistant in a hackathon?
- Do hackathon judges require you to finish the project?
- Can I join a hackathon alone or do I need a team?
- How long should I prepare before my first hackathon?
What You Need
Preparation for a hackathon is mostly physical and logistical. The creative thinking happens in the room, but everything below has to be handled before you get there.
Hardware and power
A laptop that runs your intended stack offline, its charger, and a phone with a hotspot as backup. For remote events the connection matters more than the laptop: test your dev server, your video call, and your screen share on the same network you plan to use, then again on a hotspot. Nothing stings like a demo dying because the venue wifi refused your video stream.
A working local environment
Install your language runtime, your framework, your package manager, and Git before the event. Clone or create one throwaway repository, commit something, push it to GitHub, and confirm the round trip works. That five-minute exercise on your own sofa is the difference between a confident morning and a lost hour.
Account and access groundwork
Create or confirm your GitHub account, your Devpost profile if the event runs submissions there, and your account on the event Discord or Slack. Many organizers post schedule changes, room changes, and workshop sign-ups in those channels only. Join them before the event so the noise does not arrive all at once.
Materials and personal kit
A notebook and pen beat a laptop for sketching. Also pack your registration confirmation and ID, a phone charger, a water bottle, a hoodie or layers for a room that stays cold, and snacks that do not require a microwave. Bring earplugs if you sleep lightly; a nap on an air mattress is a legitimate part of the plan.
A project concept in one sentence
Write down the problem you want to attack before you arrive, phrased as one sentence about a person and a pain. Something like helping a bus rider see arrival times for a route with no real-time sign. A sentence keeps you honest; a paragraph becomes a project you cannot finish.
An honest self-assessment
List what you can already do and what you cannot. Beginners often carry a fear of being the least skilled person in the room, and the fix is not pretending. It is naming your lane early, so the team assigns work that fits instead of discovering gaps at hour six.
Step-by-Step
1. Understand the hackathon format
Read the organizer rules page before you commit to anything. Look for the schedule, the theme or challenge list, the judging criteria, the submission requirements, and whether the event is in person, online, or hybrid. Check what a submission must contain: usually a repository link, a short video, a project description, and team member names.
Checkpoint: you can say out loud when check-in opens, when submissions close, and what you will hand in. If the schedule is a rough sketch rather than a plan, assume every hour after midnight is contested and protect your sleep block accordingly.
2. Choose a focused problem
Turn a broad interest into one specific user with one specific frustration. Smart cities, transit, energy, and open city data make excellent first-hackathon territory because the data is public and the problems are concrete. Instead of a city dashboard, build a screen that answers a single question for a single user in under five seconds.
Write the problem as: who has this problem, how often, and what do they do today instead. Then write the outcome your prototype delivers. If you cannot describe the user’s current workaround, the idea is still too abstract. Ask a mentor to read your sentence and tell you whether they understood it in one read.
3. Form or prepare a balanced team
A team of two to four beats five. Small teams lose less to coordination overhead and everyone gets to touch the demo. Useful roles for a beginner group: developer, designer, product or research, and pitch lead. Plenty of strong first-time contributions are non-coding, including data cleanup, user research, interface design, testing on a phone, and running the demo script.
Join teams through the event Discord, the organizer’s matchmaking board, the Devpost listing, your school or local developer group, or a friend who already went. If you are working alone, tell people that clearly and choose a scope small enough to build solo. Checkpoint: everyone can name their role and the first thing they will build.
4. Plan the smallest useful prototype
Define the smallest useful version in terms of one user journey. For a transit arrival tool that might be: pick a route, see the next three arrivals, tap one for details. Anything not on that path waits.
Write a cut list, the set of features you will drop in order when you fall behind, and put it in the shared doc before you start coding. Assign one person to hold the Plan B, a simpler version that avoids any integration you cannot verify, and set a trigger: if the primary path is not working with eight hours left, switch. Naming the trigger in advance keeps it from feeling like failure.
5. Prepare the technical foundation
You need far less than you think. One programming language, one front-end framework or a no-code builder, Git with GitHub, and comfort calling an API and reading its documentation are enough for most first events. Python or JavaScript covers the majority of beginner projects, and open government data usually arrives as JSON over an HTTP endpoint, which is a good first API to work with.
Do your learning before the event, not during it. If you have three weekends, spend them building one small app end to end, pushing it to a repository, and deploying it somewhere with a public URL. That single practice run teaches you more than a month of tutorials because it includes the parts tutorials skip: environment variables, broken keys, and deploying on a Friday evening.
Prepare a fallback for access problems. Download any data you plan to use to a local file, know your API key limits, and keep a copy of the documentation open locally. Checkpoint: you can start a new project, add a dependency, and push code without searching for documentation.
6. Design the user experience
Sketch your main screens on paper before writing any interface code. Three screens is usually plenty for a first project. Remove anything that does not serve the user journey, and cut features that need a second click for no reason.
Accessibility basics are cheap at this stage: readable contrast, tap targets big enough for a thumb, labels on inputs, and a layout that survives a small phone screen because most judges will open your demo on one. Checkpoint: a teammate who has not seen your sketch can describe what the app does in one sentence.
7. Build and test in short cycles
Work in short loops: build a slice, run it, watch someone use it, fix the worst thing, repeat. Branch your work so nobody breaks the demo branch, and commit small and often so any teammate can restore a working state. A shared checklist that updates as features land keeps the team from rebuilding the same thing twice.
Timebox: agree on checkpoints for the core journey, the polish pass, and the final demo rehearsal, and protect the last block for deployment rather than features. Test the prototype the way a judge will, which means on a phone, on a weak connection, and by clicking exactly the way you told the team to click. Checkpoint: someone outside the team has used it twice without you explaining anything.
8. Prepare a clear project story
Your pitch is two minutes and follows the same order every time: the problem, who has it, what you built, how it works in one technical sentence, evidence that it helps, what you did not finish, and the next step. Practice it out loud because a story told silently never sounds right when the room is quiet.
Have evidence ready even if it is thin: five people who tried it, a before-and-after time, or a screen that shows the difference. A short demo video recorded on your phone is your insurance if the live app fails. One person in the team owns the pitch, and one owns the demo, and they rehearse together.
9. Submit and present with confidence
Submit early. Most events accept a rough submission you can update, and finishing on time beats polishing past the deadline into a zero. Before you hit submit, confirm the repository is public, the live URL loads without a login, the video plays with audio, any API keys are not sitting in the code, and every team member name is spelled correctly.
During questions, answer honestly. If something is unfinished, say so and describe what you learned. Judges score the problem framing and the clarity of the demo far more often than the number of features, and beginner teams regularly lose to polished teams on story alone. Say what you built, thank the judges, and move on.
Common Mistakes
Most first-hackathon disappointments come from a handful of repeated errors, and all of them are fixable before the event starts.
- Building a platform instead of solving one problem. Six features and four screens guarantee nothing demoable. Cut to the single journey and ship it.
- Pre-coding the entire project. Starting from scratch in the room costs you the hours you needed for the hard parts. Learn the tools beforehand, then build live.
- Skipping the rules page. Submission deadlines, team size limits, eligibility, and rules about AI-generated code are all documented, and the wrong assumptions cost teams their entry.
- Ignoring mentors. The mentor sessions exist for unblocking, and experienced hackers do not mind being asked. Bring a specific question rather than a vague one.
- Holding the first working demo until the final hours. An ugly demo on hour four buys you a real feature list by hour twenty.
- Attending solo when a team was available. Solo builds are possible but they hit a wall on every task outside your skill. Team up if you can.
- Skipping sleep entirely. Tired teams demo slowly and argue badly. A planned four-hour sleep block usually improves the final presentation.
- Building on an integration with no fallback. If your only data source fails at hour twenty, you want the Plan B already written and someone holding it.
- Pushing straight to the main branch. Branching takes seconds and saves the demo when someone merges something broken.
- Pitching a product instead of a problem. Judges score clarity. Lead with who has the problem and what changes for them, then mention your stack.
One last preparation tip: the night before, stop building. Set your alarm, pack the bag, charge the laptop, and read the schedule once more. Tired people make worse scope decisions.
Frequently Asked Questions
Do I need coding experience for my first hackathon?
No. Most events run beginner workshops on things like Git, JavaScript, and API calls, and judges score the problem and the demo rather than your syntax. Teams are usually mixed on purpose, and design, product, research, testing, and pitch roles carry real weight. Say plainly what you can do when you join a team so the group assigns work that fits. Learning one language before the event is plenty of preparation.
What should I bring to a hackathon for the first time?
Bring your laptop and charger, a phone with a hotspot as backup, your registration confirmation and ID, a notebook and pen, water, snacks, warm layers, and earplugs. Test your dev server, screen share, and video call on the network you plan to use before you leave home. For in-person events, comfortable clothes matter more than you think. For remote events, your connection is the most important item on the list.
Can you use ChatGPT or an AI coding assistant in a hackathon?
It depends entirely on the organizer’s rules, and that rules page governs. Some events explicitly allow AI tooling, some restrict it to specific tracks, and some ban AI-generated code for a prize. Read the rules before you start and ask a mentor if the wording is unclear. Whatever you decide, disclose it in your submission write-up. An undisclosed dependency also breaks your build the moment the event ends, so never make AI output the only thing holding your demo together.
Do hackathon judges require you to finish the project?
Almost never. What matters is a working demo of your core journey and a clear explanation of the problem, the audience, and what you would build next. Judges can see an honest, well-framed half-finished prototype from across the room, but they cannot see an idea that never ran. State plainly what you did not finish and why. That transparency reads as judgement rather than failure.
Can I join a hackathon alone or do I need a team?
You can, and solo entries are common. Choose a scope small enough for one person, which usually means one screen, one data source, and one job to be done. You also lose the safety net: when you hit a wall outside your skill, there is nobody to hand it to. If a team is available through the event Discord, the organizer matchmaking board, or your local developer group, take it. Teams of two to four work well.
How long should I prepare before my first hackathon?
Two weeks is enough, and ten focused days is comfortable. Spend the first week on setup: install your tools, build one small app end to end, push it to GitHub, and deploy it to a live URL. Spend the second week on the event itself: read the rules, pick a challenge, find teammates, and rehearse a two-minute pitch. Extra time is better spent on a second practice build than on more tutorials.
Start with one action tonight: pick an event two to three weeks out, read its rules, and install your tools. Everything else in this guide hangs off those three moves, and the rest is practice.