What a hackathon taught me about prototyping
Build something rough in a few days, then let people react to it.
Recently I built an internal all-in-one operations platform prototype at a company hackathon.
It was rough. It was supposed to be. And it taught me more about building than a lot of polished projects have.
Why rough is the point
When you only have a few days, you can’t polish anything. You have to pick the one idea that matters and get it in front of people.
That constraint is a gift. It forces the question I should be asking on every project anyway: what’s the smallest version that shows the idea?
People react to things, not plans
I can describe an idea in a meeting for an hour and get polite nods. Put a clickable prototype on a screen for five minutes and the real feedback shows up.
“Wait, can it do this?” “That’s not how we’d actually use it.” “Oh. Oh, I get it now.”
A plan asks people to imagine. A prototype lets them react.
What I’d do again
- Pick one flow and finish it. One path that works end to end beats ten half screens.
- Fake what you can. Not everything needs to be real to test the idea.
- Show it early. The first reaction is the most honest one.
- Write down what you learned. Even if the prototype gets tossed, the notes don’t.
What a prototype isn’t
A prototype isn’t a product. It doesn’t have the checks, the docs or the approval steps that real tools need. That’s fine for a demo. It’s not fine for anything touching real work.
So the next step after a hackathon isn’t “ship it.” It’s “decide what’s worth building properly.”
The bigger lesson
AI makes the building part faster than ever. That means the hard part moves. It’s less about whether you can build it, and more about whether you’re building the right thing.
Ship imperfect, improve continuously. A rough prototype in front of real people is how you find out what “right” even means.