10 tips for running your own hardware hackathon (AI + climate tech)

This year we hosted two professional Hardware Hacks with our informal team at Studio 45 in San Francisco. The first was an Internet of Things (IoT) climate hack. The second was an AI in Motion hackathon. 

In both, participants formed teams, found problems to solve, and shipped hardware-based prototypes in 24 hours. We’ve found there are plenty of software hackathons but a lack of hardware hackathons. So we’re sharing what we’ve learned in hopes that this knowledge acts as inspiration and structure for others to host future ones. 

Some things we were intentional about that worked well: 

1. 1. Use a design fabrication space that hackers can build in. Shiny, polished office desks aren’t recommended when soldering or tinkering with hardware. We also rented plastic tables to ensure the most flexibility.
      
   2. Allow hackers to apply as a team. ~20% of those who applied had a team. They could mention that in the application, ensuring we accepted their whole team to the event. Feel free to use this page as a template for your own hack. We welcomed people of all backgrounds. The only requirement was that you were there to build and ship something. No lurkers.
      
   3. Release a library of parts one week before the hack. We shared this document a week prior to the event to let participants explore documentation. They were also encouraged to bring their own hardware.
      
   4. Kick off strong. We started the hack with coffee and an informal mix and mingling. This enabled 30 minutes of people getting to know each other. Then we had 45 minutes of programming with a founder demo from Gary Chen of Raise Robotics, where he shared a real example of what to build for. Each robot also had a robot mentor who gave an introduction to the hardware.
      
   5. For those who need a team, help them make one. We did 1-minute standup pitches and 20 minutes of mix and mingle three times on repeat until people met each other, formed teams, and then finalized teams.
   6. Be clear in the judging criteria. We made clear since kickoff that the judges would be evaluating ideas based on:Understanding the problem: Is this a big problem or does this enable an interesting future? Is there a clear customer use case?

      Demo: Is this relevant to solve the problem? Does it prove the concept (feasibility)?

      Playfulness: Is this fun or delightful to interact with? Will this demo, and system in mass deployment, create joy using AI systems and motion?

      Clear economic incentives: Is there a viable path to deploy at scale? Is there a clear reason customers would pay to use this?

   7. Submit ideas before robot pairing happens. The next 2–3 hours after team formation were dedicated to idea generation. We intentionally separated this from building to ensure teams had an idea of what they wanted to build. We also had a meritocracy where the best ideas quickest to submit got first pick at their robots.
      
   8. Have mentors floating on both sides. We had mentors on the design fabrication side and the tooling, hardware, and machine learning side available to help teams. A team of three to five mentors helped all 50 hackers.
      
   9. End strong: Alongside submitting pitch decks (2 minutes) and demos (1 minute), we wanted to make sure there was a live element to the hardware hack finale. We split the event into two parts:

Showcase (1 hour): Think startup booths with live demos. Guests and judges could meet the teams and interact with the demos.

Pitches (1 hour): These involved a 2-minute pitch and a 1-minute video demo. The embedded YouTube video in the Google slide demo ensured that everyone could see everything that was made. After each pitch, each judge had the chance to ask one question or give one point of feedback.

The final part of ending strong was having awesome judges comment on the final builds. This could be previous founders, engineers, investors, academic researchers, or other stakeholders in the ecosystem who can speak to each build, giving a candid perspective. We were fortunate enough to have judges from Google X and Waymo, as well as judges who are angel investors.

• Keep it structurally unstructured. The majority of the hackathon was focus time where each team could figure it out. We skipped the extra talks and workshops to ensure teams had as much time as they needed. Even the challenge was intentionally open-ended: “Solve a spatial challenge at home, in the office, or outside, where AI pairs up with hardware.”

Challenges and how to overcome them

Challenge #1: Too ambitious. A hackathon in itself is inherently ambitious. A hardware hackathon doubly so. When adding a layer of real world problems, climate or ai related, it can easily be overwhelming. 

Solution: Scope down the problem prompts. The climate one was open ended as we wanted teams to explore whatever they were most interested in. This was harder than it needed to be because root causes of climate change touch every industry. One way to improve this particular hack is make problem tracks, and have guest mentors or even a sponsor organization speak on behalf of the problem. 

Challenge #2: Too many robots. The first hackathon was clear: use different kits of sensor parts and boards to build an IoT device. In the second when we had a robotic arm, quadruped, roombas, and IoT kits, it quickly became too much for 50 participants. 

Solution: Simplify the parts library or bring in more people.Two ways to solve this: 1) bring in more participants or 2) scope down the parts library.

Challenge #3: Not a clear path to decide on a demo. It was enough work for teams to do problem research, that in both we found challenges going from idea to imagined demo.

Solution: Help teams storyboard in between problem research and build time.To fix this, we’ll help teams run a storyboarding exercise for future ones so they can imagine both the front end experience and the back end architecture for exactly what they need to build. 

The time is now

Hackathons are really fun. They bring together a diverse group of people who don’t usually get to work together. Hardware hackathons are even more so because the demos at the end are fulfilling for the teams as well as fun for community members to check out. 

With the latest advancements in AI tooling — like copilots and assistants — as well as cheaper sensors and great off the shelf hardware, it’s never been a better time to assemble small teams to take on ambitious challenges in the span of a weekend

P.S. If you want to support our future Hardware Hackathons in San Francisco, reach out to nate@informal.cc. We love supporting the innovation and startup community! 

informal is a freelance collective for the most talented independent professionals in hardware and hardtech. Whether you’re looking for a single contractor, a full-time employee, or an entire team of professionals to work on everything from product development to go-to-market, informal has the perfect collection of people for the job.