Hackathons don't win you customers
paul.kinlan.me
paul.kinlan.me
I know plenty of developers and founders who picked up an API (Twilio, Stripe, Paypal and Azure come to mind) at a hackday and then ended up using it commercially elsewhere. These companies aren't stupid, they're often investing 6-7 figures in marketing spend in running hackathons. They look at ROI.
It's fine if you prefer non-marketing focused hackdays, but that's totally different from saying they don't work.
The Hackathon rarely wins the customer, and it is not sustainable as a practice often due to cost and ROI is near impossible to determine.
As a standalone developer, I can think of several companies that I feel have built great "developer brand" and goodwill through hackathons, whether running their own, or sponsoring others (e.g. TC Disrupt, Startup Weekend). Twilio is the first one that comes to mind. But whether that translates into actual revenues is where my anecdotal evidence clearly falls short.
Many businesses are perfectly happy to spend 10k to acquire a customer who'll pay them 50k over the next three years.
Assuming you're not running hugely expensive hackathons a low conversion rate can still give a decent ROI.
Even if you CAC is relatively low you can still make hackathon commercially viable. A lot of smaller vendors will partner together to split the cost of hackathons between them or will become external sponsors to third-party hackathons in order to reduce the costs involved.
I went to a couple to try and build a wider network among my local devs and to try and win cool stuff.
Some went to hone existing projects using the APIs presented (to know if they actually wanted to use it)
Some went for the prizes
Some went to try and score jobs
To say any of those options are wrong really isn't right. But to tell a company why they should be there they should ask what the developers are hoping to achieve and decide if there place belongs there or not.
I will agree completely on the comment about company reps being present however. A lot of people were turned off from various companies because they were difficult to work with through different online channels and elected to not use their API simply because the cost to get it working with flawed documentation or sparse contact was too risky if they were gunning for a prize. Often the companies didn't return for the next hackathon for what I assume was because of bad reception the first time around...
Though I do think hackathons can serve different purposes. The most important thing is to be clear on the objective and don't try to win on every front. e.g. If it's to publicise your API among developers, great, focus publicity, talks, challenges around that. If it's to get feedback, same thing.
And this mirrors how developers should approach hackathons, which is again to have one clear objective. It could be to build something amazing, it could be to learn an API, but you'll rarely achieve both.
I completely agree that the optimal result for an engineering-driven hackathon is a long list of bugs and a couple of surprisingly awesome demos. But I would add a room full of excited-about-pioneering developers, and a battle-tested developer support team.