It's been almost been about three years since my first hackathon and I've now won prizes at nine hackathons (more if you count meme/small hackathons), organized judging at a hackathon and was a judge myself twice. Crafting the perfect project is certainly isn't a science, but I've found some things that usually work™.

1. Don't skimp on the brainstorming.

Most hackathons work out to judge with 25% from technical difficulty. Some hackathons might value usability as another 25% which could also be related to your coding. Yeah it's a coding competition, but you must have the right idea. I have been able to get around this annoyance if I notice a number of technical judges who will appreciate a project just because it's cool <3. Here are a few questions I think about regarding an idea;

• Is this novel? If not, does it do it much better than the original?
• Is this impactful? How soon will it be impactful, and will that impact demo well?
• Is this technically interesting? If not, how can it be spiced up?
• How will this project demo?

2. Don't skimp on the planning.

Working in a team is hard. Trying to design a full featured project and build it in 36 hours is hard. Sleep deprivation makes it worse. Trying to figure out what needs to get done and how will be insanely hard. Planning includes making sure that all team members know what they're doing, and how all the parts will fit together. If a certain feature depends on another one, it would be a good time for someone to sleep. When considering "optional" features, set a time so that you know at which point you should give up and move onto something more essential. When planning, consider that some features may be a pain to implement but will never show up in the demo, or will only partially show up in the demo. For those, just have a UI or a single type of case that can be demoed and let the judges know.

3. Pair.

Code written at hackathons is bad, and gets exponentially (may be factorial, more data is needed) worse as time progresses. It's almost always more efficient to have someone around for a sanity check, especially if they wrote some of the surrounding code.

4. Start by programming the "new" things.

Coding when tired is hard. Reading documentation when you're so tired that everything is blurry is hard. If you're working with a new kind of database, write yourself a query/push/update/delete first, and let your team know where it is. Same goes for SDKs, sending requests from React for the first time, etc. People often don't do that, since it yields working "parts" more slowly, but trust me this is #worth. This also means being A G I L E and spreading out your work rather than fully finishing one "part" then moving onto the next. Additionally, this will let you know early on if something isn't technically feasible.

5. Have a good sleeping pattern.

Power naps are much more efficient than just crashing for twelve hours near the end. I like to wake up for the last six hours of the hackathon. This gives me enough rest to be able to efficiently rescue last-minute bugs and demo without being a zombie. Another good time to sleep is right after planning, though I like to have one person awake to scaffold the project. It's near impossible for four people to actively work on a fresh project at the same time.

6. Talk to sponsors and judges during the hack.

This is especially great when going for category/API prizes. Most people will be willing to give some pointers or new ideas that would make your hack more interesting. Sometimes it'll be more like "Dude, this idea will never work ever". With API prizes, they may share some magical feature that you didn't know about and will save you hours. On top of that, the sponsors will (hopefully) have a better impression of your team. Often I have projects with an "Oh shit" moment, or a "LITTY!!!!" moment that are I wouldn't have without talking to others.

7. Demo and talk.

Judges can get seriously bored listening about the next big thing. Never separate the "talk" and the "demo". Just do it at the same time. Demos are flashy, and you want to make sure to capture every possible feature. Rehearse your demo more than your speech (especially if the project is somewhat buggy). Another point to mention, is that your idea should be awesome to demo. This often means hardware, things happening in realtime or some other magical "waaaaaw" moment.

8. Don't bullshit.

Maybe the one judge you get doesn't catch it, but they'll tell the other judges who likely will. I've disqualified people who comically oversold, totally missed the idea of blockchain, reused ideas or made up some facts about MRI scans (seriously?).

9. It's a good sign if your judge asks questions.

Usually, they're not just trying to hurt your feelings and/or ruin your life. They're actually interested in how your project works. How you answer these questions are easily more important than the initial demo. Remember that when they ask a question, it's not an invitation to start discussing an entire different aspect of your project. I've yet to encounter any question that would take more than a few sentences to answer.

10. STOP TALKING.

If a teammate answers a question, you don't need to add-on (unless it was seriously inadequate). If a feature is described, the implications of that feature are often intuitive. If your project is interesting enough, then it's always safer to say less as then the judges will ask questions. Even if it isn't interesting, a lot of judges will pick up on fact that you may have undersold and will prod you about it.

Other silly things that aren't quite worth another point or related to winning;

• Stressed programming is also bad. Go play games; go cup stacking or do yoga. PET THE THERAPY DOGS. Plus if you win cup stacking, you're still a H A C K A T H O N W I N N E R 🤔
• Sometimes when you're REALLY tired, you start forgetting what you're trying to do. Try making a list of comments in your code as a to-do list.
• Be awake for closings. Having your team showing up to the stage and being like "Where is John? Oh I see he's passed out on the table back there." is awks.
• Don't try to build a project that covers every single category and API prize.
• Feed yourself. But not just chips. Have a salad.
• Write decent commit messages; especially for the last couple hours. Finding a bug during demos and having no idea when it happened is very yikes.
• Other people will hate you if you use blockchain wrong. Or if you just plug a random model into AR. Or if you use an API and advertise your "machine learning" hack. ¯\_(ツ)_/¯. It will sometimes push you towards a win but do you really want to win that way? DO YOU?