This is a repost from our old blog. Originally written by Milo Davis.
One of the first things you decide when you come to a hackathon is what you’re going to build. As someone who has had projects both succeed and fail at hackathons, I feel like I’ve gained some insights into what works and what doesn’t. Below are some questions to help you check yourself before you wreck yourself.
1. Am I delaying doing something because it’s going to be hard?
Save yourself from your future self. If you ever get to a part of the thing you’re building and think, “This seems pretty complicated. I’ll get to it later”, you are in the danger zone. Do it right away! Think about how smart you are now, now imagine yourself at least 40% more stupid. That’s you after not sleeping for the next 20-48 hours. Suck it up, get it done now.
2. Does someone here know about the tools I’m using?
Build something new, build something cool, but don’t use tools so obscure that you can’t find resources to help you. This applies to both obscure platforms and languages without well-documented libraries. Run from the words “can fail silently” and things that will be impossible to debug. Mentors are also a great resource, but they can’t help you if they’ve never heard of the language, platform, or hardware you’re working with. Pick something that, even if you don’t know it, is still known.
3. Do we have enough time to finish?
Take it from someone who has been ridiculed by his friends for the past year for messing up time estimation, do something you are sure you can finish. Your project will grow to fill the time allotted, so be reasonable.
4. Are there multiple levels of success here?
Pick something simple, but that’s easily extendible. Get an easy core working first, then add more to it. For example, if you’re building a game, try to build a single level and then add more levels or a multiplayer mode if you have time. Don’t start complicated: choose a project that has simple, attainable goals, that you can build on when and if you finish.
5. Did we just pick the first idea we thought up?
This one isn’t a hard rule, but you can never get better than your idea. If you choose a good idea and execute it poorly, you’ll probably fare better than a poor idea executed well. Also, it’s a lot easier to fix your implementation as time goes on than your idea at the beginning. So pick something you’re really happy with then start, not the other way around.
6. Does everyone know what we’re building?
It’s hard enough to build something when everyone agrees on what they’re building and pretty much impossible when people don’t. It may seem obvious, but do yourself a favor: get everyone on the same page before you get started. It’ll save you some grief down the road.
In conclusion, think through what you do before you start and know what you are capable of. I’ve failed or seen others fail because they didn’t think through the weekend when they started. Push the limits, push your limits, but know your limits and you’ll build something awesome.