Validation
Validate your idea quickly against real constraints and judging criteria.
The Lego Method
Don't try to validate the whole idea at once. Build small, tested building blocks — like Legos — and snap them together into a winning project.
The biggest mistake teams make is trying to build the entire project in one shot, then discovering at hour 18 that a critical API doesn't work the way they assumed. The fix is simple: validate one piece at a time, in isolation. Make each block solid. Then combine them — and the project assembles itself.
Test one integration, one API, one flow at a time. Can you get a streaming response from OpenAI? Can you trigger a phone call through Twilio with a Python script? Can you make a text-to-speech model output audio in a browser?
Each question gets its own isolated experiment. No dependencies, no distractions.
Once a block works, make it reliable. Handle the failure modes. Understand the rate limits. Know the latency. A block you've battle-tested in a side project is a block you can trust at 3AM during the hackathon.
A solid block never breaks during the demo. That's the whole point.
When each block is proven, combining them is straightforward. OpenAI streaming + Twilio voice + a React frontend = a voice AI agent. The architecture emerges from the blocks you already trust.
Composition is fast when every piece already works. The project assembles itself.
Think of it like actual Legos: you don't mold custom plastic at build time. You pick pre-made blocks off the shelf and connect them. The more blocks you've tested beforehand, the faster you build during the event.
Pre-Hackathon Validation
Critical: validation happens BEFORE the hackathon, not during it. Your side projects are your lab. Use them to build a library of proven blocks.
The hackathon itself is for combining and creating, not for discovering that an API doesn't work. Every hour spent debugging a basic integration at the event is an hour stolen from building the thing that wins.
- OpenAI streaming responses — test latency, token limits, error handling
- Twilio voice calls — triggering, receiving, and processing audio
- Supabase real-time subscriptions and auth flows
- File uploads, WebSocket connections, deployment pipelines
Weeks before
validate tools during side projects
then combine
then combine
- Combine proven blocks into the new idea — focus on the novel integration
- Spike only the one NEW risky piece — the part that's never been tested
- Skip re-validating proven tools — trust the blocks you already built
- Spend the saved hours on polish, pitch, and demo prep
Day of
validate only the new and risky
Pro tip: Research hackathon sponsors and their APIs before the event. Build small experiments with their tools during side projects. When the hackathon starts, you already know what works, what breaks, and where the free credits run out.
Spike Solutions — Test the Riskiest Piece First
From Kent Beck's Extreme Programming: a small, throwaway experiment to test a risky technical assumption before committing to a full implementation.
“A spike solution is a very simple program to explore potential solutions. It focuses only on the problem under examination while ignoring all other concerns. Most spikes are not good enough to keep, so expect to throw away the code.”
— Kent Beck, Extreme Programming
The Rule
Every hackathon idea has one piece that could kill it. Find that piece and test it first. If the spike fails, pivot the idea before investing more time. If it works, you've just de-risked the entire project.
Example Spikes
Can GPT-4 actually triage 911 calls accurately?
~ 45 min spike
Can Twilio handle real-time audio streaming to an LLM?
~ 30 min spike
Can we run inference fast enough for a live demo?
~ 60 min spike
Richard Feynman — Nobel Laureate in Physics
“What I cannot create, I do not understand.”
If you can't build the smallest version of the riskiest piece, you don't fully understand the problem. The spike is how you earn that understanding — fast.
Why This Works — The Science of Rapid Validation
The Lego method isn't just intuition — it's backed by decades of engineering and design research on how to validate fast and build with confidence.
“The goal of the MVP is to begin the process of learning, not end it.”
Each Lego block is a mini MVP cycle. Build the smallest testable version, measure whether it works, learn from the result. Repeat for the next block. By the time you combine them, you've already learned what matters.
— The Lean Startup, 2011
“If a picture is worth a thousand words, a prototype is worth a thousand meetings.”
IDEO's design philosophy: stop debating whether something will work and just build it. A 30-minute prototype answers more questions than a 2-hour whiteboard session. Build, don't debate.
— David Kelley, IDEO founder
“A tiny implementation that performs a small end-to-end function, linking together the main architectural components.”
Before adding features, get one path working from UI to logic to data. The skeleton proves your architecture works. Once it's walking, flesh it out — but never start with the flesh.
— Alistair Cockburn, Agile Manifesto co-author
“Tracer bullets show what you're hitting. This may not always be the target. You then adjust your aim until they're on target. That's the point.”
Like tracer rounds that show where shots land, tracer code implements one narrow path through all layers. It gives you real feedback on whether your architecture works — before you commit to building everything.
— The Pragmatic Programmer, 1999
The Validation Ladder
A four-step progression from 'can we technically do it?' to 'can a judge use it and understand it?' Each step builds on the last.
Proof of Concept
1-2 hoursCan we technically do it?
Internal experiment, 1-2 hours, one person. Test the hardest integration — the piece most likely to kill the idea. Throwaway code is fine. You're testing feasibility, not building product.
Walking Skeleton
2-4 hoursCan we connect all the pieces?
The tiniest end-to-end path through UI, logic, and data. User clicks a button, backend processes something, result shows on screen. It doesn't need to be pretty — it needs to be connected.
Prototype
4-8 hoursDoes the flow feel right?
Clickable, interactive, shows the user journey. Test it with a teammate — can they use it without explanation? If they're confused, the flow needs work before you add more features.
Demo-Ready MVP
By submissionCan a judge use it and understand it?
Working product with a polished happy path. The core flow is smooth, the UI is clean on the main screens, and the demo tells a story. Edge cases don't matter — the golden path does.
You don't have to climb every rung at the hackathon. If your Lego library is strong, you might start at step 2 or 3 on day one. Pre-validation compresses the ladder — that's the whole advantage.
Two-Way Door Decisions
Most hackathon decisions are reversible. Make them fast. Save your deliberation for the few choices you can't undo.
“Most decisions are two-way doors. If you make the wrong decision, you come back in and pick another door. But some decisions are one-way doors — you go in that door, you're not coming back.”
— Jeff Bezos, founder of Amazon
- Tech stack choice — can always swap a library
- Feature scope — add or cut as you go
- UI layout — iterate quickly
- API choice — test one, swap if it fails
< 5 min
decide and move on
- The core idea — pivoting mid-hackathon costs hours
- Team composition — roles set the trajectory
- The problem you're solving — shapes everything
- Which prize track to target — determines constraints
Take your time
these decisions are hard to undo
Spend 80% of your decision-making energy on one-way doors. Make two-way doors in under 5 minutes. The teams that lose aren't the ones who pick the wrong framework — they're the ones who spent 2 hours debating which framework to use.
Reid Hoffman: “If you aren't embarrassed by the first version of your product, you shipped too late.” Perfect decisions aren't the goal — fast, reversible decisions are.
“What I cannot create,
I do not understand.”
— Richard Feynman, Nobel Laureate in Physics
In hackathons, validation IS creation. Build the smallest possible version of each piece. If you can't make it work in isolation, it won't work in the full project. Don't assume — prove it with code.
Your Lego library is your competitive advantage. Every block you've already tested during a side project is hours saved during the event. While other teams are debugging their first API call at hour 4, you're composing proven blocks into something that already works.
The team with the most pre-validated blocks wins — because they spend the hackathon creating, not discovering.
Validation Checklist
A step-by-step summary for de-risking your hackathon project. Follow this before and during every event.
Build a "Lego library" of tested blocks during side projects before the hackathon
Identify the riskiest technical assumption in your idea — spike it first, in 30-60 minutes
Get a walking skeleton working in the first 2 hours — one path, end to end, UI to data
Validate each block in isolation before combining — never test two unknowns at once
Make two-way door decisions in under 5 minutes — save deliberation for one-way doors
If the spike fails, pivot the idea immediately — don't sink more time into a broken assumption
"What I cannot create, I do not understand" — if you can't build the smallest version, rethink the approach
Remember: The goal of validation isn't to prove your idea is perfect — it's to find out what's broken before you're 18 hours deep with no backup plan. Test early, test in isolation, and trust the blocks you've already proven.