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, just 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. Once you combine them, 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, including latency, token limits, and error handling
- Twilio voice calls, from triggering and receiving to 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 and focus on the novel integration
- Spike only the one NEW risky piece, the part that's never been tested before
- Skip re-validating proven tools and 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.
Sponsor Recon
Before the hackathon, research every sponsor. Visit their docs, sign up for their APIs, and run a quick validation. The teams that win sponsor prizes are the ones who showed up already knowing the tech.
Most hackathons publish their sponsor list weeks before the event. That's your window. Every sponsor is a potential prize category, a set of free credits, and a technology you might build on. The teams that walk in cold, reading docs for the first time at the event, are already behind.
Visit every sponsor's developer docs. Sign up for their API. Read the quickstart. Can you get a “hello world” running in 30 minutes? If not, that's a red flag you need to know about before the event, not during it.
If the docs are bad or the API requires manual approval, plan around it.
Rate limits, approval wait times, missing SDKs for your language, deprecated endpoints, pricing tiers that cap out mid-demo. These are the things that kill projects at 2AM. Find them in advance so they don't surprise you.
Run the API end-to-end in a throwaway project. Trust working code, not marketing pages.
Build a tiny proof-of-concept with the sponsor's tech. If it works, you now have a validated Lego block ready for hackathon day. If it doesn't, you saved yourself from building your entire project on a broken foundation.
A 30-minute test now saves 3 hours of debugging at the event.
Bonus: Sponsors notice when you use their tech well. Some judges are sponsor employees evaluating how deeply teams engaged with their platform. Showing up with pre-existing knowledge of their API signals that you're serious.
Pick Your Stack
Lock in your tech stack before the hackathon. Your default should be tools you've used before. Only swap components when a sponsor makes it worth it.
The best hackathon stack isn't the most cutting-edge one. It's the one you can build fastest with. Have a default stack you've battle-tested in side projects, and only deviate when there's a strategic reason (like a sponsor prize).
App Router, React 19, TypeScript. Server components for speed, client components for interactivity. Pair with shadcn/ui and Tailwind for a polished UI in minutes.
Swap when: The hackathon requires a specific framework, or you're building a mobile app (use React Native or Flutter).
Python backend with async support, automatic OpenAPI docs, and first-class compatibility with every AI/ML library. Most AI sponsor SDKs ship Python-first, so your backend should too.
Swap when: You need real-time WebSockets at scale (use Node), or the project is frontend-only (use Next.js API routes).
Postgres database, auth, storage, and real-time subscriptions in one service. The free tier is generous enough for any hackathon. Set up auth in 10 minutes instead of building it from scratch.
Swap when: MongoDB is a sponsor (use MongoDB Atlas), or you need a vector DB for RAG (add Pinecone or pgvector).
The swap rule: Only replace a component in your default stack if (1) a sponsor is offering a prize for using their tech and you're targeting that prize, or (2) the project genuinely requires it. Never swap just because something is trendy. The hackathon is not the time to learn a new database.
Target Your Prize
Before the hackathon starts, study the prize categories and pick 1-2 to aim for. This decision shapes your idea, your tech stack, and your pitch.
Most teams show up, build something cool, and then figure out which prize to submit for at the end. That's backwards. The winning teams pick their target prize first and reverse-engineer everything from there. The prize description tells you exactly what the judges want. Read it like a rubric.
Sponsor prizes typically require using a specific API or platform. Fewer teams submit for these because they require research and integration effort. If you've already validated the sponsor's tech (see Sponsor Recon above), you have a real advantage.
- Read the prize description like a scoring rubric
- Make the sponsor's tech central to your demo, not a side feature
- Mention the sponsor by name in your pitch
Every team is implicitly competing for “Best Overall.” This is the hardest prize to win because you're up against everyone. To win it, your project needs to be impressive across the board: technical depth, polished UI, strong pitch, and a compelling problem.
- Optimize for “wow factor” in the demo
- Your pitch needs to be airtight since every judge sees it
- Polish matters more here than in sponsor categories
Pro strategy: Target one sponsor prize as your primary and “Best Overall” as your stretch. Build for the sponsor category, then polish enough to be competitive overall. This doubles your chances without splitting your effort.
The Go Bag
A curated set of pre-built, pre-validated components you bring to every hackathon. These are the Lego blocks you've already tested, ready to snap in on day one.
Experienced hackathon teams don't start from scratch. They show up with a go bag of reusable scaffolds, configs, and components that they've already battle-tested in side projects. The go bag isn't pre-built features for the hackathon project; it's infrastructure that every project needs, already solved.
- Supabase Auth with Google/GitHub OAuth pre-configured
- Protected route middleware you can drop into any Next.js app
- Login/signup pages that already look polished
Auth is the #1 time sink at hackathons. Never build it from scratch.
- A shadcn/ui navbar, sidebar, and dashboard layout ready to go
- Dark mode toggle, responsive breakpoints, and a consistent color palette
- Loading states, error boundaries, and toast notifications
A polished UI in the first hour makes the whole project feel real.
- An OpenAI Agents SDK scaffold with tool-calling and streaming already wired up
- Prompt templates for common patterns: summarization, extraction, classification
- RAG pipeline with chunking, embeddings, and vector search
Most hackathon projects now involve AI. Have the plumbing ready.
- Vercel deployment config with environment variables templated
- Docker Compose for local development with hot reload
- A .env.example with every API key slot you commonly use
Deploy in the first hour. A live URL makes everything feel real to judges.
Build your go bag during side projects, not the night before. Every component in the go bag should be something you've used at least once in a real project. If you haven't tested it, it's not a Lego block; it's an unknown. Keep the go bag in a private repo and update it after every hackathon with what you wish you'd had.
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 lets you earn that understanding quickly.
Why This Works — The Science of Rapid Validation
The Lego method goes beyond 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.
“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.
“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, you can flesh it out. Just never start with the flesh.
“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 actually works, well before you commit to building everything.
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, but it does need to be connected.
Prototype
4-8 hoursDoes the flow feel right?
Clickable, interactive, shows the user journey. Test it with a teammate and see if they can 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, and 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.”
- Tech stack choices, since you can always swap a library
- Feature scope, which you can add to or cut as you go
- UI layout that you can iterate on quickly
- API choice, where you test one and swap if it fails
< 5 min
decide and move on
- The core idea, because pivoting mid-hackathon costs hours
- Team composition, since roles set the trajectory
- The problem you're solving, which shapes everything
- Which prize track to target, because it determines your 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
Research every sponsor's API and docs before the event, and run at least one validation test per sponsor
Lock in your default tech stack (Next.js + FastAPI + Supabase) and only swap components when a sponsor prize justifies it
Pick your target prize category and reverse-engineer the judging criteria from the prize description
Pack your go bag: pre-validated auth, UI components, agent scaffolds, and deployment configs
Identify the riskiest technical assumption in your idea and spike it first, in 30-60 minutes
Get a walking skeleton working in the first 2 hours, covering one path end to end from UI to data
Validate each block in isolation before combining, and never test two unknowns at once
Make two-way door decisions in under 5 minutes and save your deliberation for one-way doors
If the spike fails, pivot the idea immediately instead of sinking 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.