10 Hackathon Wins: My Rapid Prototyping Framework

People assume hackathon winners are fast coders. They're not. They're fast deciders.

The difference between a winning team and a losing team isn't typing speed. It's how quickly they answer three questions: What are we building? What's the minimum that works? What do we cut?

After 10+ wins across Italy, Spain, Mexico, and the US, I've distilled the hackathon process into a rapid prototyping framework that I use for every product I build. The framework works whether you have 36 hours or 36 days.

The Framework: Demo-Backward Design

Most teams design forward. They start with the idea, build features, and hope the demo comes together at the end.

Winning teams design backward. They start with the demo and build only what the demo requires.

Step 1: Write the demo script first. Before any code, write the exact sixty-second presentation you'll give. What do you say? What do you show? What does the audience see on screen? The demo script is the specification.

Step 2: Identify the critical path. What's the minimum set of features that makes the demo script work? If the demo shows a user uploading a photo and getting a result, the critical path is: upload, process, display result. Everything else (user accounts, error handling, settings, history) is off the critical path.

Step 3: Build the critical path first. Spend 60% of your time on the features that appear in the demo. Spend 20% on making them look presentable. Spend 20% on contingency: what breaks and how do you recover during the live demo.

Step 4: Hardcode everything else. If the demo doesn't show user authentication, hardcode the user. If the demo doesn't show the settings page, it doesn't exist. If the demo shows three results, generate three results and hardcode the fourth for safety.

This framework sounds like cheating. It's not. It's scope management under extreme time pressure. And it produces better demos (and better products) than the "build everything" approach.

The Decision Stack

Speed in prototyping comes from eliminating decisions, not from making decisions faster.

Every decision costs time. "Should we use React or Vue?" costs an hour. "Should we use Postgres or MongoDB?" costs thirty minutes. "What color should the button be?" costs fifteen minutes. Multiply by fifty decisions and you've lost two days to deliberation.

Here's my decision stack, a pre-made set of choices that eliminates deliberation for every project:

Language: TypeScript. Always. For frontend, backend, and tooling.

Frontend: Next.js. App Router. Tailwind CSS. No debate.

Backend: API routes in Next.js for simple projects. Separate service for complex ones.

Database: MongoDB for unstructured data and rapid iteration. Postgres only when I need relational integrity.

Auth: Simple token-based for prototypes. Upgrade later if it matters.

Hosting: Vercel for Next.js projects. Always.

AI: Claude API for generation tasks. Switch models only when there's a specific reason.

Payments: Stripe. No alternatives considered.

This stack isn't objectively the best for every situation. But it's the stack I know deeply enough that I never waste time configuring, debugging, or learning. The best stack is the one that doesn't slow you down.

Pre-deciding your stack isn't laziness. It's recognizing that stack decisions have minimal impact on product success and maximum impact on development speed.

The 80/20 of Features

Every product has a core interaction, the one thing users do that delivers the core value. Everything else is scaffolding.

For Aviation Infinity, the core interaction is: answer a question, get feedback, improve. The study engine, the adaptive algorithm, the progress tracking: that's the core. Everything else (account settings, social features, certificate generation) is scaffolding.

For ClickAi, the core interaction is: describe your business, get a website. The voice input, the generation pipeline, the rendering: that's the core. Everything else (domain management, analytics, SEO settings) is scaffolding.

For LegalAgento, the core interaction is: describe your legal problem, get matched with an attorney, receive attorney-reviewed documents. That's the core. Everything else (attorney profiles, review systems, payment history) is scaffolding.

Build the core interaction first. Make it feel magical. Then add scaffolding only as users demand it.

I've launched products with no settings page, no profile editing, no notification preferences, because users didn't need those features to experience the core value. They needed them eventually, and I added them eventually. But "eventually" can be months after launch.

Prototyping Tactics

The Fake Door Test

Before building a feature, put a button for it in the UI. Don't build the feature, just the button. Track how many people click it. If 30% of users click "Export to PDF," build the export. If 2% click "Share to social media," don't.

This works in hackathons (put buttons for features you might build, see which ones judges ask about) and in production (launch the button before the feature to validate demand).

The Wizard of Oz

If the AI isn't working, be the AI. In early LegalAgento prototypes, some of the "AI-generated" documents were templates I filled in manually based on the user's input. The user experience was identical: they submitted information and received a document. The fact that a human prepared it instead of an AI was invisible.

This technique validates the workflow before you invest in the technology. If users don't want the output (regardless of how it's produced) the AI implementation won't save you.

Parallel Validation

Don't build features sequentially and validate them sequentially. Build three features in parallel and validate them simultaneously. This is counterintuitive because sequential seems more focused. But parallel validation saves time because you discover which features matter before you've invested deeply in any of them.

In hackathons, I build three partial features in the first twelve hours and commit to the two that work best for the remaining twelve. The feature I cut is always one I was convinced would be the highlight.

The Two-Hour Rule

If a feature takes more than two hours to implement in a prototype, it's too complex. Simplify it or cut it.

This rule isn't about capability. It's about signal. If a feature is hard to prototype, it's either poorly defined (which means you don't understand it well enough) or genuinely complex (which means it'll take weeks in production). Either way, it doesn't belong in a prototype.

From Prototype to Product

The biggest mistake I see (in hackathons and in startups) is treating the prototype as the product.

A prototype proves the concept works. A product proves the business works. They're different things with different requirements.

A prototype can hardcode. A product can't.

A prototype can ignore error states. A product must handle them gracefully.

A prototype can serve one user. A product must serve thousands.

A prototype can run on localhost. A product must run reliably in production.

The transition from prototype to product is where most hackathon projects die. The team won the hackathon, celebrated, and never did the unglamorous work of turning a demo into a service.

My approach: build the prototype to prove the core interaction works. Then rebuild the critical path with production architecture. Don't incrementally improve the prototype code. It's throwaway by design. The prototype taught you what to build. Now build it properly.

This is counterintuitive to engineers who hate "wasting" code. But the fastest path to a good product is: prototype fast (learn what works), then rebuild properly (build what works). The alternative (building properly from the start) is slower because you're building properly before you know what "properly" means.

The Speed Compounds

After 10+ hackathons and ~20 products, the prototyping speed compounds.

Not because I type faster. Because I've solved the same problems enough times that the solutions are pre-loaded. Authentication? I've built it dozens of times. Payment flow? Dozens of times. Search? Dozens of times. Admin panel? Dozens of times.

Each repetition deposits a pattern in memory. The pattern isn't code. It's decision architecture. How to structure the database for this kind of problem. How to design the API for this kind of interaction. How to handle the edge cases that always appear in this kind of feature.

This is the compound return on building many things. You get faster not because you work harder, but because you've seen more. And seeing more means deciding faster. And deciding faster means shipping faster.