First Place at the KOSTAL Hackathon 2025
Half the build time went to battery problems. We spent the rest deliberately building the slower car — and that is why we won.
Watch the run: KOSTAL Hackathon 2025 ↗
The brief at the KOSTAL Hackathon 2025 was concrete: a Raspberry Pi car had
to follow a marked path, read QR codes along the way, and complete the
course. Eight hours on the schedule. We won it with about four.
The four hours we did not plan for
Battery problems ate the first half of the day. Not dramatically — no smoke,
no dead hardware — just the slow kind of failure where the car behaves
differently on the third run than on the first, and you spend an hour
establishing that the code is fine and the power is not.
That hour is the one that decides hackathons, and it is never in anyone's
plan. What it left us with was roughly four hours for everything: writing
the control logic, planning the run, and testing enough to trust it.
Why we deliberately built the slower car
With half the time gone, the obvious move is to go faster. We did the
opposite, and that decision is the reason this post exists.
The fast approaches all had the same shape: they worked beautifully in the
common case and had a tail of situations where they did not. A tighter line
through a corner is quicker until the marking passes out of view. A higher
speed between checkpoints gains seconds until a misread sends the car off
the path and someone has to place it back by hand.
Every one of those edge cases is a debugging session, and we no longer had
debugging sessions to spend. So the rule for the rest of the day became:
prefer the option with fewer ways to fail, even when it is visibly
slower.
In practice that meant conservative speeds, generous margins where the car
had to recognise something, and control logic simple enough to reason about
without running it. Nothing in the build was clever. That was the point.
Reliability is what is actually being scored
It felt too cautious while we were doing it. Other teams were visibly
quicker, and a slow car looks like a car that is not finished.
But a hackathon is not scored on the best run — it is scored on the run that
happens in front of the judges, once. A car that completes the course at
eighty percent speed beats a car that is twice as fast and fails one attempt
in three. Under that scoring, "slow and certain" is not the timid choice.
It is the correct one, and the gap between those two readings is where most
of the field loses.
Our stack stayed deliberately small: the Raspberry Pi car, Python for
control, and simple checks to keep it on the path. With four hours, the
constraint is not what you can build. It is what you can still verify.
What I took from it
The technical part of that day was unremarkable, and I think that is the
interesting bit. We did not win because we wrote better code than anyone
else. We won because we spent our remaining time on the thing most likely
to decide the outcome, and then refused to trade that away for speed we did
not need.
Under time pressure, the instinct is to compress the work. The better move
is to compress the risk — decide what must not fail, and let everything
else be slower than it could be.