Rules

Rules are subject to change leading up to the event

1. Be Excellent To Each Other

This is, by all means, the most important rule. This is a very diverse environment, made up of many races, religions, sexual orientations, genders, and gender identities. Any behavior or presentation that objectifies or belittles others will be halted, with the presenters immediately disqualified and removed from the event. Don’t behave in a way or present anything you wouldn’t be proud to have your parents see. For more information surrounding our policies on harassment, please click here.

2. Actually Build Something

This isn’t a Powerpoint-athon! Build and demonstrate a working project, don’t just show us screenshots and slides.

3. Write Your Code Here

The project you present must be coded entirely during the Hackathon. The only exceptions are for publicly available frameworks/APIs and open-source code that has been available for at least a month. If it feels shady to use the code, don’t.

4. Code Audits

Finalists will have their code audited to make sure it’s all new and legit, by a developer appointed by TechCrunch. Your code belongs to you and we won’t share it with anyone, but we will want to see it if you win.

5. Track Your Code

Use Git or an equivalent to track your code as you write it. It’s good practice, and if it comes down to an audit, it’ll help you prove your code is new.

6. Build Something New And Great

This isn’t an opportunity to promote your team’s pre-existing product. Don’t tack one tiny feature onto your existing product and call it a day.

7. Present The Project You Submitted

You must present your hack as described in your submission – if you deviate from your accepted submission, we’ll have to boot you from the stage. Don’t submit one thing and then abuse the stage and respect of the audience to present something different.

8. Team Size Limit

We’re limiting the number of members per team at 5, in the interest of keeping things fair. All other things equal, it’s not very reasonable for a team of 2 or 3 to compete against a team of 20.

Also, we strongly suggest that each hacker gives their attention to just one team, rather than trying to be a part of multiple projects; we want to see your best work, and it’s hard to do your best work when you’re jumping from table to table.