Tag Archives: TCDisrupt

Impressions from TechCrunch SF Hackathon Part 2

TechCrunch hosted a hackathon before the 2012 TechCrunch Disrupt in SF this weekend.  Part one of this post deals with Hackathon logistics and presentations; Part 2 will be some quick thoughts on some of the ideas presented. Here are some of the overall impressions followed by tweet-length reactions to the 60-second presentations. You can see all the demos here and the top winners with videos and pics are available here. Continue reading

Impressions from TechCrunch SF 2012 Hackathon Part 1

TechCrunch hosted a hackathon before the 2012 TechCrunch Disrupt in SF this weekend. Wanted to push out some quick impressions for both the companies that demo at Hackathons as those looking to host/participate in future hacks. Part one of this post deals with Hackathon logistics and presentations; Part 2 will be some quick thoughts on some of the ideas presented.

Some basic rules/tactics to cover off at a minimum:

  • If you have 60-seconds on stage do ALL the boring stuff before you get on stage—that means set up monitor for mirroring. Clear cache, have everything demo-ready
  • Limit to 2-people per hack to minimize congestion; and really for 60-seconds you should only have one presenter unless you’ve got a role for each of the other folks on stage
  • Make an impression–Display stickers so #is visible in video/pics w/Name for judging b/c sometimes names get confused, presentations jump out of order & stuff happens
  • Make a lasting impression–don’t hack until you get on stage; leave at least an hour to run through and refine your main talking points, places for humor or impact and repetition of your name/solution/problem you’re solving
  • Demo your app first 
  • List apis/technologies used quickly at the beginning or in the end w/credits to thank the amazing resources that helped you get there, but don’t sell them as a differentiator or key feature. It shouldn’t be last thing people hear/remember, but please give credit where credit’s due; plus you’re more likely to win API-specific prizes if you give the shout-out
  • Have your presentation flow tightly choreographed between screens, server-calls, etc. Know which ones take longest and which will cut out if WiFi isn’t working (which is likely b/c everyone’s on it or blocking good signals w/their mifi networks). Consider cut/paste options and other shortcuts if involved input is required.


  • Don’t trust the tech–we’re still in a “can you hear me now” world even at the best-prepared/run events
  • Don’t get lost in the features and forget to share the idea (tough b/c you’ve just spent 24 sleepless hours in feature analysis/focus land)
  • If fast pitching, consider having 2-3 podiums vs 1 table. Understand it means you need more Elmos, etc. to make that work. Would allow pitch bug delays to be minimized and feature the work
  • Focus on pitch, not on the screen—distractions lead to disjointed delivery
  • It’s a marathon & you win by getting it past the finish line–many of the presenters acted like just being on stage was the finish line; it’s not. You need to close FTW
  • Keep going until they kick you off
  • Sponsor apps get more time to present/fail
  • Native language presenters aren’t necessarily the best presenters—go with the most entertaining b/c even if the demo sucks they’ll still remember you—but if you can have both, it’s better b/c you’re usually trying to convey some complex thoughts into a simple story
  • If you’re on a team, don’t lean over and tell the presenter they only have 20-seconds left—distracting & it’s conf organizer’s job to manage anyway—like a coach; your job is done when they go on the field.

And, if you’d like to see a well-run Hackathon recap, enjoy the Big Brand Hackathon we hosted earlier this year with Kraft Foods and The Home Depot: