Hackathon Wins Across 4 Countries Taught Me to Ship Fast

My first hackathon was in Milan. I didn't win. I barely shipped. The project crashed during the demo, the pitch was incoherent, and I walked out thinking I'd never do another one.

I went back the next month. And the month after that. And then I started winning.

Over the next several years, I won 10+ hackathons across four countries and three continents: Italy, Spain, Mexico, and the United States. Projects for Google, Facebook, ForeFlight, and Whirlpool. Events at Rice University, UC Santa Barbara, Expo Milan, and the US-Mexico border.

These weren't side activities. They were training. Every skill I use today as a founder (rapid prototyping, ruthless prioritization, clear communication under pressure, and the ability to ship imperfect work) I developed in hackathon after hackathon.

What a Hackathon Actually Is

For people outside the tech world, a hackathon sounds chaotic. And it is.

You show up on a Friday evening with a laptop and maybe a vague idea. You form a team, sometimes with people you've just met. You have 24 to 36 hours to build a working product and present it to judges. Then you go home and sleep for fourteen hours.

The constraints are extreme:

• Time: 24-36 hours. Not days. Hours.
• Team: 2-5 people, often strangers with unknown skills.
• Resources: Whatever's on your laptop plus free APIs and cloud credits from sponsors.
• Scope: Must be demoable. A slide deck doesn't count. It has to work.
• Judging: 60-90 seconds to present. Sometimes less.

These constraints create an environment where the normal rules of software development don't apply. Code quality doesn't matter. Test coverage doesn't matter. Documentation doesn't matter. The only thing that matters is: does it work, and can you explain why it matters?

The Wins That Taught Me the Most

HackTravel 2015 — Milan (Winners with Special Honors)

The challenge was to build something for the travel industry. We built a platform that connected travelers with local experiences, not tours, but real activities with local people. Cooking classes, neighborhood walks, market visits.

What I learned: The idea doesn't have to be original. The execution does. Airbnb Experiences didn't exist yet, but the concept of "local experiences" wasn't new. We won because the demo was polished and the pitch told a story about human connection, not features.

Expo Milan 2015 (1st Place)

This was at the World Expo, a massive venue with teams from across Europe. The theme was food and sustainability. We built a food waste tracking system that helped restaurants measure and reduce waste.

What I learned: Judges care about impact, not technology. Our technology was simpler than most competitors'. But our pitch quantified the impact ("this restaurant would save 300kg of food waste per month") and judges responded to concrete numbers over abstract potential.

HackRice 2017 — Houston (1st Place)

Rice University. The challenge was open-ended. We built a tool that used computer vision to analyze border crossing queues, the same concept that eventually became BorderBot.

What I learned: Solve a problem you personally experience. I was living on the US-Mexico border at the time. The border crossing wait was a daily frustration. The judges could feel that the project came from genuine frustration, not from browsing a problem list.

HackSB 2018 — Santa Barbara (1st Place)

UC Santa Barbara's hackathon. We built an accessibility tool that used voice commands to navigate web applications for visually impaired users.

What I learned: Accessibility problems are hackathon gold. They're underserved, they have clear impact, and they're technically challenging enough to impress judges. More importantly, they matter.

The Skill: Building Under Pressure

Hackathons compress the startup experience into a weekend. Every skill I use as a founder traces back to lessons learned under hackathon time pressure.

Scope Ruthlessly

At hour zero, every team has a vision for a feature-complete product. By hour four, reality hits. The API doesn't work. The design takes longer than expected. The team member who was supposed to handle the backend is stuck on authentication.

The teams that win are the ones that cut scope fastest. Not "let's simplify the design." Real cuts. "Let's remove three of the five features and make the remaining two actually work."

In my startups, I apply this constantly. Every product I build launches with fewer features than I planned. Not because I'm disciplined by nature, but because hackathons trained me to see the minimum viable demo and build only that.

Ship Imperfect Work

Hackathon code is terrible. Hardcoded values. No error handling. Console.log everywhere. Variable names like temp2 and fixThisLater.

And it works. It ships. It demos.

This lesson is harder to internalize than it sounds. Engineers are trained to write clean code. Founders are trained to ship. Hackathons teach you that shipping ugly code that works is infinitely better than clean code that doesn't ship.

I still write imperfect first versions. The difference is that now I know when to come back and clean up, and when "good enough" truly is good enough.

Pitch the Problem, Not the Solution

The biggest rookie mistake in hackathon demos is spending sixty seconds explaining how the technology works.

Nobody cares how it works. They care why it matters.

"We built a computer vision system that analyzes queue density using convolutional neural networks with a YOLO-based object detection model" gets blank stares.

"We tell you how long you'll wait at the border before you drive there" gets attention.

This lesson transformed how I pitch every product. Aviation Infinity isn't "an adaptive learning platform using spaced repetition algorithms." It's "the AI flight academy that helps you pass your pilot exams." A legal AI platform isn't "an AI-powered marketplace for limited-scope legal representation." It's "get a lawyer for $75 instead of $500."

Trust Strangers

Most hackathon teams form on the spot. You don't know your teammates' skills, work styles, or reliability. You have to trust them, and they have to trust you, within hours.

This taught me to assess people quickly. Not through interviews or references, but through observation. Who starts coding within the first hour? Who's still debating the idea at hour four? Who says "I'll handle the backend" and actually handles it?

In my companies, I hire based on similar signals. Not credentials. Not portfolios. Action. Speed. Follow-through.

Why I Co-Founded HackIfy

After competing in hackathons across three continents, I wanted to bring the experience to the US-Mexico border.

HackIfy.io was the first binational hackathon between San Diego and Tijuana. Developers, designers, and entrepreneurs from both sides of the border, building together in a shared space.

The border is a wall in every political conversation. In the tech community, it doesn't have to be. Mexican and American developers share tools, languages, and problems. A hackathon was the simplest way to prove that.

We ran HackIfy multiple years. Each time, the projects got better and the community grew. Teams that met at HackIfy went on to start companies together. Developers who'd never crossed the border started attending meetups on the other side.

Building community is slower than building products. But it compounds in ways that are impossible to quantify.

From Hackathons to Startups

Every product I've launched started with the same energy as a hackathon project: a small team, a tight deadline, and a determination to ship something that works.

Aviation Infinity's first version was built in the same intensity as a hackathon, a working prototype in weeks, not months. ClickAi's first demo was a hackathon-speed sprint. Many of my products each started with a weekend of intensive building before expanding into full development.

The difference between a hackathon project and a startup isn't the initial intensity. It's what happens on Monday morning. Hackathon projects usually die because nobody maintains them. Startups survive because someone cares enough to keep building after the adrenaline fades.

I've been on both sides. The hackathon projects that became real products (BorderBot, the concepts behind Aviation Infinity's early features) succeeded because the problem kept bothering me after the event ended. The problems I forgot about on Monday morning were never real problems to begin with.

The Compound Effect

10+ hackathon wins sounds impressive on a resume. But the wins themselves aren't the point.

The point is the compound effect of repeatedly building under extreme constraints. Each hackathon made me faster. Each pitch made me clearer. Each team taught me something about collaboration. Each failure (and there were many between the wins) taught me what not to do.

By the time I was building my fifth product, I could prototype faster than most teams could plan. By my tenth product, I could scope a project in an hour and build the first version in a weekend. After a dozen products, the patterns were so internalized that building felt like muscle memory.

That speed (the speed of someone who's shipped dozens of projects under impossible deadlines) is the real value of hackathons. Not the prizes. Not the resume lines. The skill of turning an idea into a working thing, fast, under pressure, with imperfect information.

If you're an engineer and you've never done a hackathon, go to one. If you've done one and didn't win, go to another. The skill compounds. And it translates to everything you'll build after.