HackIfy: Building a Hackathon Discovery Platform

Hackathons changed my trajectory as a builder. But finding them was harder than it should have been.

In 2017, hackathon information was scattered across university websites, Eventbrite pages, Facebook groups, and word-of-mouth channels. If you wanted to know what hackathons were happening near you this month, you had to check a dozen sources. If you wanted to know which ones were worth attending (which had good prizes, strong mentors, and interesting challenges) you had to ask around.

HackIfy was my attempt to solve this: a centralized platform for discovering, comparing, and tracking hackathons. Think of it as what Product Hunt does for product launches, but for hackathons.

The product was straightforward. The lessons were not.

The Product

HackIfy aggregated hackathon listings from multiple sources into a single, searchable directory. Each listing included:

• Event details: dates, location, format (in-person, virtual, hybrid)
• Prizes and sponsors: what you could win and who was backing the event
• Tracks and themes: AI, fintech, healthcare, social impact, open
• Requirements: student-only, professional, beginner-friendly, experience required
• Registration status: open, closed, waitlisted

Users could filter by location, date, theme, and skill level. They could save events to a watchlist, get notifications when registration opened, and read post-event writeups from attendees.

The technology was simple: a Node.js backend scraping event pages and aggregating data, with a responsive frontend for browsing. The hard part wasn't the code. It was the content.

The Content Aggregation Problem

Content aggregation sounds simple: collect information from multiple sources, normalize it, and present it in a unified interface. In practice, it's a series of annoying, never-ending problems.

Sources are inconsistent. One hackathon posts a detailed page with dates, location, prizes, and tracks. Another posts a single paragraph with a registration link. Extracting structured data from unstructured sources required manual curation that didn't scale.

Data goes stale. Hackathon dates change. Registration deadlines extend. Events get cancelled. Keeping hundreds of listings accurate required constant monitoring, or accepting that some percentage of listings would be wrong at any given time.

Completeness vs. quality. Do you list every hackathon you find, including the poorly organized ones with no prizes and twenty attendees? Or do you curate, risking that you miss something valuable? I chose completeness initially and learned that users preferred quality. A curated list of twenty great hackathons was more useful than an exhaustive list of two hundred mediocre ones.

The bootstrapping problem. A directory with ten listings isn't useful. Users won't come until there's enough content. But creating enough content requires effort that's hard to justify without users. This chicken-and-egg problem affects every content platform, and there's no shortcut. You just have to do the manual work until the flywheel starts.

I spent weeks manually curating hackathon listings. Visiting university websites, checking MLH (Major League Hacking) schedules, monitoring Twitter for announcements, reaching out to organizers directly. The initial dataset was entirely hand-built.

What I Learned About Community Products

HackIfy was my first community-oriented product, one that depends on user participation to create value. The lessons were transferable to every community product I've built since.

Communities need density. Ten users spread across ten cities don't form a community. Ten users in the same city do. For HackIfy, this meant focusing on regions with high hackathon density (California, the Northeast, major university cities) rather than trying to cover everywhere at once.

Lurkers are the majority. For every user who contributed a review or updated a listing, a hundred users just browsed. This isn't a problem to solve; it's a feature to accept. The small number of active contributors create value for the large number of passive consumers. The product needs to work for both.

Timing is everything. Hackathon discovery is seasonal. University hackathons cluster around the academic calendar: fall semester and spring semester. Summer has fewer events. Marketing HackIfy during peak hackathon season produced ten times the engagement as marketing during the summer lull.

User-generated content needs moderation. When I added the ability for users to submit hackathon listings, the quality varied wildly. Some submissions were detailed and accurate. Some were spam. Some were legitimate events with wrong dates. Moderation (reviewing, editing, approving) consumed more time than I expected.

Project vs. Product

HackIfy crystallized a distinction that I now think about constantly: the difference between a project and a product.

A project is something you build. It has a start, an end, and a deliverable. You can build it in a weekend, a week, or a month. When it's done, it's done.

A product is something you maintain. It has users, expectations, and ongoing needs. It requires updates, bug fixes, content refreshes, and operational attention. It's never done.

HackIfy started as a project ("I'll build a hackathon directory this month.") It became a product when people started relying on it. The transition was gradual and caught me off guard. One week I was building features. The next week I was responding to users who reported stale listings, asked for new filters, and complained when events were missing.

The maintenance burden of a content platform is particularly heavy. Code maintenance is predictable: fix bugs, update dependencies, add features. Content maintenance is ongoing: every listing needs verification, every event needs updating, every new hackathon needs adding.

This lesson shaped my approach to every subsequent product. Before building anything, I now ask: "What does maintaining this require?" Not just the code maintenance, but the content maintenance, the user support, the operational overhead. If the maintenance burden exceeds my capacity, the product isn't viable as a solo effort, no matter how good the initial build is.

The Technical Lessons

Beyond the product lessons, HackIfy taught me specific technical skills:

Web scraping is fragile. Scrapers break when source websites change their HTML structure, which they do regularly and without warning. A scraping-dependent product requires constant monitoring and fixing. I learned to build scrapers that fail gracefully and alert me when they break, rather than silently returning bad data.

Search is harder than it looks. Building a search experience that returns relevant results requires understanding user intent, handling misspellings, weighting different fields appropriately, and presenting results in a useful order. I started with a simple text search and ended up learning about full-text indexing, relevance scoring, and faceted search.

Performance matters for directories. A directory with hundreds of listings needs to load fast, filter instantly, and paginate smoothly. This pushed me to learn about database indexing, query optimization, and frontend performance, skills that I'd use in every subsequent project.

Email notifications are a retention tool. The weekly digest ("5 new hackathons near you this week") was the highest-engagement feature. Users who signed up for notifications came back regularly. Users who didn't, churned. This taught me that retention features (notifications, digests, reminders) are more important than discovery features for long-term engagement.

Why I Moved On

HackIfy served its purpose: it helped me find hackathons, it helped others find hackathons, and it taught me how to build, launch, and maintain a content product.

I moved on because the maintenance burden exceeded the learning value. Every hour I spent updating hackathon listings was an hour I wasn't building new things or developing new skills. And as my interests shifted toward aviation technology, the motivation to maintain a hackathon platform naturally decreased.

HackIfy also taught me that not every problem needs a product. Hackathon discovery was a real problem, but it was also a problem that the community was already solving through informal channels: MLH, university networks, social media. The incremental value of a dedicated platform wasn't large enough to justify the ongoing effort.

The right lesson isn't "HackIfy was a bad idea." It was a good project that would have been a grueling product. Knowing the difference is one of the most important things it taught me.

The Hackathon Pipeline

What HackIfy gave me, beyond the direct lessons, was a pipeline into the hackathon world. Through building and maintaining the platform, I connected with organizers, sponsors, and participants. These connections led me to hackathons I wouldn't have found otherwise, including CalHacks at Berkeley, which would become one of the most important experiences of my building career.

Products don't just create value for users. They create connections for builders. The network effect of building in public (showing your work, sharing your tools, contributing to a community) compounds in ways that are hard to predict but consistently valuable.

HackIfy was a small product with a short life. But its second-order effects (the skills, the connections, the lessons) are still compounding years later.