Written by Tudor Evans.As Jean-Luc Godard once said, every story has a beginning, a middle and an end - but not necessarily in that order.Allow me, then, to start at the end, and tell you that I won my company’s annual hackathon (well, I won in one of three categories to be precise).The winning ticket was a MacOS dictation app. Instructions for use were as follows. Put cursor in text area. Press right option. Speak. Win.Simple, clean, effective. Your voice was your keyboard wherever you went. It was, in the lingo of the online youth, “wiggety-wack”.Alas, this was no triumph for me. Rather, it was a relief. It was a relief because I’d spent the previous week pointedly telling everyone that I really, really was going to win the hackathon, and that there was no point in them even competing.Imagine the humiliation if I’d fallen short!You might wonder where I got my overwhelming confidence from. Was it my dashing good looks? My charm and my wit? My can-do attitude? How could anyone, I hear you cry despondently, be confident of winning a hackathon in this day and age, when AI can generate a million lines of working code in a week?Despond no more, friend. For I am here to share with you the secrets of my craft - the keys to the eternal kingdom of coding victory, if you will.1. The art of the hustleWinning a hackathon is rather like increasing one’s share of an inheritance: it helps to poison the other interested parties. Alas, poison is not in our approved arsenal of weapons on this occasion, and we aren’t in the midst of an Agatha Christie novel.But we are allowed to use Claude code, which feels about as close as one can get to cheating without resorting to murder. If you’re not using Claude to code these days, your odds of winning a hackathon are precisely zero. And even if, like Han Solo, you don’t want to be told the odds, nevertheless the odds are there.There is no way a mere mortal can compete with Claude in a hackathon. It’s just so damned good at churning out boilerplate. It’s like drinking rocket fuel. Or coding on crack. Or any other performance-enhancing drug.Actually, in truth there are other forms of cheating. It’s here I should mention that I started my project a week early. Now this may sound like outrageous trickery. And it is. But a few words must be offered in my defense.First, I told everyone I was doing this, giving them the opportunity to take on my gauntlet. Second, as Donald Trump once said about avoiding taxes: that makes me smart. At the end of the day, the free market doesn’t reward waiting for the start date. Hard work pays off. That being said, I was burnt out basically the entire week afterwards, so make sure you take time off too!2. The need for visionVision is the defining factor for software engineers and product developers today. I knew from the start what the product I was shooting to build would look like.Just as governing without ideals is a fool’s errand, so building without vision will get you nowhere. Vision is like the breath of life which inflates an otherwise lifeless balloon. It gives form and substance to the things you try to build, and ensures that when critical design choices come to a head, the needs of the bigger picture take precedence over this or that quick hack.To give a concrete example, I rejected the UX used by other transcription tools where the text is dumped out into your text editor all in one go. This had benefits and drawbacks - not least that it made the technical implementation more challenging! - but it was all driven by the vision. This wasn’t a dictation tool, it was a voice keyboard, goddamn it!So the most important lesson I have to give is this: if you want to win, don’t start from the perspective of “this would be cool”. Don’t start from the perspective of “the judges will like this”. Instead, ask yourself: what does a world look like in which other people actually use this thing I’m building?Keep the vision of a real, concrete product in mind. That one step will already get you into the tenth percentile of hackathon projects.3. Experimenting with techI made some pretty whacky choices in the tech stack. I wanted to build it with Golang, as that’s one of the main languages we use at Speechmatics. That design choice, made at a time when I didn’t appreciate how things would evolve, led me down some interesting routes. Most notably, it meant I avoided using Electron and similar technologies, which are a pretty standard way of creating cross-platform desktop apps these days.Electron is great in many ways, but like Duran Duran’s eponymous wolf, it’s very hungry. A typical Electron app might consume around a gigabyte of RAM in order to run. Instead, I went with a package called Wails, which does for Go what Tauri does for Rust (okay, now it might sound like I’m speaking in tongues). It also has the advantage of being homophonous with my country of origin, Wales.That package allowed me to bundle a single page React UI into the app with a memory usage of 100MB - an order of magnitude less than an Electron app! What did I do with that extra memory, you might wonder? Fear not that it went to seed. I made good use of it implementing on-device transcription, which left me roughly break-even with other transcription tools.How much of this, though, could really be said to be my choice? Almost none. Though I acted as supervisor, all due credit must go to Claude for writing the code. Our financial controller reliably informs me I’m the number one user of Claude in the company. And almost all of that usage happened across the one wild week of the hackathon, when I would often keep whispering to my AI agent/new best friend until 2am.This is one of the great powers of AI coding assistants. In the past, an architectural choice like this would be heavily belaboured over. If I had to write it myself, I surely would have chosen Electron because it was the safe option. I was sure to get it working eventually; it was tried and tested. I only knew about Wails because Claude told me. Yet since I knew I (read: Claude) could rewrite the whole thing according to a different architecture within hours, the risk of choosing a novel approach was almost zero. That freed me up to make an otherwise dangerous choice which in the end paid off dividends.https://www.youtube.com/watch?v=-Ob7M4V8fU4&embedable=true4. A winning presentationIf you want to win, it’s not enough to have a great product. You need to sell it. A lot of great products have failed to take off, not because the tech was poor, but because it was sold badly. Don’t be that nerd who’s too clever to communicate with other people.Admittedly, that’s easy for me to say. I’ve always found presenting comes naturally to me. This isn’t about some secret trick, or that one simple thing that makes communication work. It all comes down to one simple thing. I’m naturally enthusiastic and I get excited about the things I do. If I’m good in front of a crowd, it’s only because I’m able to give off the energy that I bring to the things I care about, and people respond to that. For anyone looking to get better at public speaking, this would be my biggest piece of advice - bring the enthusiasm you have for what you do into talking about what you do. It’ll make all the difference.That, and bribing the audience.Since the product was pitched as a legal dictation tool as much as anything else, I brought our senior legal counsel onboard for the demo. I know what you’re thinking. You’re thinking I was running the risk of being upstaged by that famously charismatic class of person, the lawyer, who always tries to steal the limelight with their flashy jokes and quick wit.Thankfully, Naomi knew her place, and stuck to the script after only the shortest round of beatings.Domain expertise is a great way of showing off the quality of your product. It’s a bit like holding up a giant placard that says “LOOK, I SOLVED A PROBLEM” except it’s considerably less needy and weird (I’m already needy and weird enough, thank you very much!).The icing on the cake was when she tried to use emojis during legal dictation, which gave me the excellent opportunity to turn to her and say, in my most supercilious of tones, that you should never use emojis in a legal document. Queue laughter from the audience - and note that humour is a great way to win over the voting public, or an angry mob at a pinch.The victorySo, there you have it. To win, you must:Poison your competitorsStart earlyCheatGet something else to write your codeCo-opt other, more trustworthy people into your presentationBut it’s not just about getting there. How you win is as important as how you won. Remember, in victory, to behave appropriately. Make sure the other participants are aware that they lost. Remind them of this with phrases like “LOOOSER” and “GET WRECKED”. Gently suggest that they belong in a bin, because they ain’t nothin’ but trash.Or you could be nice to your colleagues and remember that it’s all about having fun and making friends.I mean, it’s your call.But at what cost…?I want to come to one final point. We’ve spent so much time in this article contemplating if we could, that we never even asked if we should. After all, why should we care to win a hackathon in this day and age, when software is a dime a dozen and the world is going to hell in a hand cart?Should we not instead look up from our machines and take in the wonders of nature? Should we not spend our evenings glorying at the sight of another sunset? Should we not attend to the feeling of a fresh summer breeze flowing through our hair? Should we not, in sum, focus our attention on all that this beautiful creation we call Earth has to offer for the ennoblement of our immortal souls?To which I say: no. Victory is all that counts.Happy hacking!