Hackathon Winners

May 21, 2018

My crew during the Hack the Road hackathon organised by BeMyApp at the F1 circuit Zandvoort in the Netherlands. We did not win, because the 1st prize went to the “cheapest to implement idea”. Dutch…

During the years I have been asked to work w/ a number of hackathon winners as a development coach.

A role I have always done w/ a great joy.

The conversations I have had so far show some similarities among all the hackathon winners, which I would like to summarise here.

1. How to Start a Startup

I began recommending all hackathon winners to watch the 1st two lectures from Sam Altman’s Stanford University Course How to Start a Startup.


They contain some important and still up-to-date, proven wisdom, some of which very much matches my experience, so I quote it frequently.

2. Technology

A frequent question I receive is: “Is this the right technology?”

My answer is usually: “For the Proof of Concept or even for the Prototype, use the technology you and your crew are most comfortable with.”

During a Proof of Concept/Prototype phase, which most hackathon winners face after a hackathon†, the technology is not as critical as the speed of implementation.

3. What to focus on?

The Proof of Concept/Prototype phase, following a hackathon, is a usually a (very) short one.

My advice is always to focus on what will demonstrate the idea.

For example, do not waste time to implement a login subsystem. Everybody knows that login subsystems are possible and that there are well refined best practices.

4. Solve a problem you have

Stolen from Sam Altman.

Some of the most successful inventors and startups have solved a problem they have had.

The challenge related to solving a problem is how well do you know the problem. You never know a problem you know about as well as a problem you have yourself, especially an acute one.

5. Solve the problem for a small group, which will worship you

Stolen from Sam Altman.

It is good to have a vision, but even the longest journey starts w/ and mostly consists of small steps.

Solve the problem for a small group, which will worship you. This is usually easy, cheap and, as Sam Altman says, it is easier to spread something from people, who love it to people who like it. If the original group just like it, it is unlikely that the wider group will like it too.

6. Create a rhythm

Many hackathon participants come from different locations and meet online.

It is very good to have regular meetings or at least a planned next meeting w/ clear expectations and clearly defined deliverables.

A deliverable can always be defined. If you cannot define the deliverable, than the deliverable should be to define a deliverable for the next iteration.

7. Create time and sort out early

Many hackathon participants have a day job or attend a university, so it is often difficult and challenging for them to find time when to contribute to the Proof of Concept/Prototype.

This one is a cruel one, but participants must find time and contribute regularly. Or contribute to specific work packages/milestones (i. e. create the presentation, create a video, create a web site), at a specific phase of the Proof of Concept/Prototype project.

If a participant keeps disappearing, it is time to have a clear cut and remain w/ a smaller, but dedicated crew. To help keep the crew, on another hand, it is good to have early on a clear idea what you want to deliver, what effort it will require from each of you and if the participants are really up to it.


† Provided they are true hackers and not (semi-)advanced startups or even commercial companies who abuse hackathons for marketing/funding purposes. Which is an unforgivable violation of the chevalier code of conduct as I see it, and I am rather conservative in this respect.

Go top