What a winning hackathon submission looks like
3 August 2026 · Superteam Argentina · 6 min
Solana hackathons through Colosseum get thousands of submissions. Judges are volunteers with day jobs, working through a queue. Assume roughly three minutes of attention, and assume the first ten seconds decide whether you get the other two minutes fifty.
That is not cynical. It is the constraint you are designing for.
The video is the submission
Everything else is supporting evidence. Most teams spend three weeks on code and forty minutes on the video, then wonder why they did not place.
A structure that works:
- 0:00–0:15 — what it does, in one sentence, over a shot of the working product. No logo animation. No "hi, we're team X". No slide.
- 0:15–1:30 — the demo. Real clicks. Real transactions. Show the thing failing gracefully if that is honest.
- 1:30–2:15 — why it needs a blockchain, and why Solana specifically. Judges are looking for a reason this is not a Postgres app with extra steps.
- 2:15–3:00 — what is next and who you are.
Under three minutes. Record it twice, keep the second one.
Ship something that runs
A deployed program on devnet with a working frontend beats an elegant architecture diagram every single time. Judges click the link. If the link is broken, you are done.
Before you submit:
- Open your own link in an incognito window on a phone
- Make sure the repo is public and the README says how to run it
- Put the devnet program ID somewhere visible
- Check the video is not set to private — this happens constantly
Pick a track and actually fit it
Side tracks are where the real odds are. The main prize has thousands of competitors; a sponsored track might have thirty. Read what the sponsor cares about and build toward it deliberately rather than submitting the same project to everything and hoping.
If you are Argentine, this matters twice over: regional tracks and local sponsor prizes are consistently under-subscribed.
Scope down, hard
The projects that place are almost never the most ambitious. They are the ones where the demo works. A single flow, finished, beats four flows half-built.
If you are three days from the deadline and the core loop does not work end to end, cut features until it does. Every time. This is the single most common failure and the easiest to avoid.
Write the description like a human
The submission text is not a whitepaper. Say what it does, who it is for, what you built during the hackathon versus what existed before. Judges respect honesty about the latter and notice when you dodge it.
What we can do
Superteam ARG runs squads for the big hackathons — teams, mentors, and rehearsals before submission. Members get their demo torn apart by people who have judged before, which is considerably less painful than being torn apart by the actual judges.
Resources
- Colosseum — the hackathons themselves
- Solana developer docs
- Superteam Earn — bounties are good hackathon practice
- Solana Foundation grants for what comes after
Apply to be a member before the next one opens.