// in this post
I've now entered an AI hackathon both ways. The first time, in a team of three spread across three continents, we reached the finals. The second time I went in alone. I didn't win, but I learned a tonne about working on my own on a topic where I'm not usually the expert, and about what I'm like with a 24-hour clock running.
In this piece I'll show you both builds, talk you through the decisions that mattered, and share my tips for entering your first one. In June I wrote that building with AI under pressure is the fastest way to find out where it's heading. This is the write-up I promised.
If you haven't been near one: a hackathon gives you a fixed window to build a working product against a brief, and then you present it to judges. Both of mine could be done from my own desk.
With a team: Workforce Pulse
The first was World Wide Vibes 2026, run by GenAI Works. Our team of three, spread across three time zones and continents, built Workforce Pulse, a dashboard for Montgomery, Alabama. We were one of about twenty finalist teams.
The idea was mine, and it came from something that has always bothered me about hiring. People looking for work face barriers, and recruitment doesn't do a good job of seeing them. If you're on welfare, you need to know how taking a job will affect your benefits. If you're young and inexperienced, you need to know what training comes with it. If no public transport gets you near the workplace, you need to know that before you apply, not after you've been offered the job. I wanted to build something that deals with a person's reality, not just their CV.
What we built in the time was the first version of that. You start with who you are, long-term unemployed or a young person not in work, education or training, and switch on the barriers you face, like having no car or no degree. The jobs, the training programmes and the picture of local skills gaps all reshape around you.
Three programme pages from Workforce Pulse with the "no car" barrier switched on. The third programme is open to this person, but the job it leads to needs a car, so the app flags it before they enrol.
My part was the idea, the coordination, and the entry video and copy. The building was my teammates'.
As the de facto "manager" of the team I found keeping the team motivated and in sync a challenge. Our back-end engineer was super motivated, which I think helped the rest of us, but the eight or so hours' time difference left little time for ideation, feedback, or improvements that could have been the difference between being shortlisted and winning the competition.
Looking back, it was a proper role. Someone has to decide what the thing is for and who it's for, and someone has to tell the story at the end. None of that is code. I did that job and nothing else, and four months later I had to do it and everything else.
On my own: FairShot
The second was Hack-Nation's 6th Global AI Hackathon, 24 hours, and I went in alone. I'd done the team version and wanted to see what it was like without one.
The brief, from the Maschmeyer Group, was The VC Brain: build the machinery a venture fund would use to find founders, assess them and reach a decision. Venture capital isn't my field. Assessing people for potential is, and it turned out to be the same instinct as Workforce Pulse. Funds judge founders on networks and pedigree because that's what's visible, the way recruitment screens on a CV, and both miss the person.
FairShot's pipeline, running on its demo data. Every profile marked Synthetic is invented.
So FairShot, which I built with Claude Code, scores a founder on what they've actually done. It rates four traits (ability, aspiration, learning agility and accountability) from evidence, it's allowed to answer "insufficient evidence", and it has a hard list of things it must never score on, like school, age, gender or nationality. Then it interviews the founder by voice and checks their claims while they're still talking.
Working alone changes the job. In March I had one role. Here I had all of them: product owner, architect, tester, the person writing the pitch. Claude Code could write the code. It couldn't decide what to build, what to leave out, or whether what came back was any good. Three decisions did most of the work.
Plan before you build
After the first hour I had a working core. Then I stopped building and spent the next couple of hours on a spec and a build plan, including a cut list: what goes first if I'm running out of time, and what never goes. A couple of hours of not building, with the clock running, felt wrong. It was the best call of the weekend, because after that I wasn't deciding things, I was carrying them out.
The cut list didn't survive contact with the weekend. The voice interview was on it, and I built it that same evening, because by then I was thinking about the demo. A founder answering questions out loud while the system checks them live is the moment the idea lands. A cut list written early in the evening is about risk. Treat it as your best guess at the time, not a promise.
Put the rules in code, not in the prompt
If a model can make something up, eventually it will. A sterner prompt won't stop it. Code that makes it impossible will. FairShot's evidence grader can only cite web pages the search actually returned: the model proposes a source, the code checks it against the pages the search saw, and anything else is thrown away. The interview's follow-up questions aren't governed by "please keep them to a minimum". A counter allows one per question and two per interview.
It's the same thinking as the rota app I built for my wife: compute what you can, and never let the model write silently.
Have someone read it who isn't trying to be kind to you
On the Sunday morning, a few hours before the deadline, I stopped building and had the code reviewed the way a judge would read it, not the way the person who wrote it does. It found a list of real problems. Two applicants who both pasted a LinkedIn link were being merged into one person. And the fairness rules lived in the code, but the model never saw them in its instructions. That taught me the other half of the last decision: code can enforce what it can check, but a rule you want the model to follow has to be somewhere the model can read it.
All of them were fixed in one commit.
How I'd choose
Having done both, here's where I've landed.
Go for it, and don't worry about it. If you're thinking about entering, enter. It's fun and it's hard, and you'll learn things in a day that no amount of reading will teach you.
Team up if you can, ideally with someone who's done it before. You'll see how other people work, and you won't be carrying every decision yourself.
If you go alone, you'll find out what you're like under pressure. I work alone a lot, and a hackathon is a good test of that.
Work out your role early. In March mine was the idea, the coordination and the entry video. In July it was everything, with Claude as the engineer. If you build with AI and you land in a team with a back-end engineer, the question to ask is what you're there to do. The answer isn't nothing, and it isn't the code. It's deciding what's being built and for whom, keeping the team pointed at the same thing, and telling the story at the end. That's also what I was doing for Claude.
What I haven't tried is a team with a back-end engineer in it while I use Claude alongside them. How that changes the answer is the part I still want to find out.
FAQ
What is a hackathon?
A fixed window, often a weekend, in which you build a working product against a brief and then present it to judges. Both of the ones I've entered can be done online, from your own desk. The one in July gave us 24 hours.
Should I enter a hackathon alone or in a team?
If you can, join a team, ideally with someone who has done it before. You'll see how other people work and you won't carry every decision yourself. Going alone is a good test of what you're like under pressure, and it means you play every role. I've done both: I reached the finals as part of a team of three, and the second time I entered on my own.
Do I need to be able to code to enter an AI hackathon?
Not for the role I had in March, where my part was the idea, the coordination and the entry video and copy. In July Claude Code wrote the code while I made the decisions and reviewed what came back.
What are Workforce Pulse and FairShot?
Workforce Pulse is a dashboard for Montgomery, Alabama that reshapes jobs, training and local skills gaps around a job seeker's situation and barriers. My team of three built it for World Wide Vibes 2026, run by GenAI Works. FairShot is a venture capital operating system I built on my own for Hack-Nation's 6th Global AI Hackathon: it scores founders on evidence, interviews them by voice and checks their claims while they speak. The code is public under an MIT licence at github.com/paul-thehuman/fairshot.