Your choice of tech stack can be make or break at a Hackathon. It can be the difference between rapidly iterating on an app in a fun domain, or tearing your hair out because it just-won't-build.

So when your team comes to the dreaded "what stack should we use?" discussion, we need some criteria to make that decision.

First, let's describe what kind of tech we want to use at a hackathon.

1. We want tech that can get us from 0-to- Hello world! quickly. We've on a deadline. We want project generators, templates, and one-click setups. We want example code that can be easily copy-pasted.
2. We want simple tech. Not everyone on the team will be familiar with the choice of stack. We want small API surfaces. We want terse, well written documentation.
3. We don't care that the tech is not fully featured. We're not going to run into its constraints in just a few days. And maybe we like operating in a constrained environment, that might lead to creative solutions that will impress judges.
4. We want to be able to quickly collaborate and iterate. We're going to be stepping on each others toes when an entire team tries to tackle the same problem all at once.
5. We want everyone to be able to contribute. It's no fun to be left out of a team. Every team member should be able to do meaningful development work on Mac, Linux or Windows, and Android or iOS if you're developing a mobile app

Rapid prototyping tools

This is a bit of a hot-take, but I think rapid prototyping tools have improved dramatically in the last few years. They offer the right mix of high-level composability to smash out straightfoward tasks with enough low-level flexibility when you need to stray off the beaten track.

<aside> 💡 You can win a hackathon using a rapid prototyping tool. They are emblematic of the hack aspect of the competition. Don't do more work than you need to.

</aside>

Heres what I recommend: