About HackFinder

A hackathon discovery platform born out of frustration, built with modern tools, and deployed at the edge.

Why I Built HackFinder

As someone who regularly participates in hackathons, I found the experience of discovering events frustrating. Hackathons are scattered across Devpost, MLH, HackerEarth, and other platforms — each with their own interface, their own search quirks, and no way to see everything in one view.

I kept missing deadlines or discovering great events too late because there was no single source of truth. HackFinder solves that by aggregating hackathon data from multiple platforms into one searchable, filterable interface.

Beyond solving a real problem, this project also serves as a portfolio piece demonstrating full-stack development, edge computing with Cloudflare, and modern web architecture — all built from scratch using a spec-driven workflow.

How It Was Made

Built with Kiro — an AI-powered IDE

This project was built using Kiro's spec-driven workflow, which guided the entire process from requirements gathering to deployment. Here's how it came together:

  1. 1

    Requirements

    Defined 8 requirements covering data aggregation, search, filtering, responsive UI, SEO, and deployment.

  2. 2

    Design

    Architected the system with Astro + Cloudflare Pages/Workers/D1, an adapter pattern for data sources, and FTS5 for search.

  3. 3

    Task Breakdown

    83 tasks organized into waves, each building on the previous — from schema design through UI polish.

  4. 4

    Implementation

    Code generated and verified task-by-task with 230 unit tests ensuring correctness at every step.

  5. 5

    Deployment

    Deployed to Cloudflare's edge network for global performance — entirely on the free tier.

Want to build something like this?

Check out Kiro — the AI-powered development environment that guided this entire build from requirements to deployment.

A note on naming

The product is called HackFinder in the UI — short, punchy, and clean in a nav bar. The repo and subdomain use hackathon-finder — the full word helps with SEO (people search "hackathon finder", not "hackfinder") and makes the URL instantly clear to anyone who sees it. This is the same pattern real products use: a branded name for the interface, the descriptive name for discovery.

Deployment gotchas we hit

Building this was smooth until deployment. Here's what actually tripped us up — in case it saves you time:

  • KV namespace conflict: The Astro Cloudflare adapter auto-provisions a "SESSION" KV namespace. If you deploy, delete, and redeploy, it fails because the namespace already exists. Fix: disable sessions with session: false in astro.config.mjs.
  • D1 binding timing: The first Cloudflare deploy always fails because you can't add D1 bindings until after the project exists. It's a chicken-and-egg problem — deploy once (it fails), add the binding, then redeploy. This is expected.
  • Empty database ≠ broken: After a successful deploy, the site shows "Failed to load hackathons" — this looks like a bug but it's just an empty D1 database. You need to run the migration and trigger the aggregation worker separately.
  • database_id in wrangler.toml: The Cloudflare git integration's deploy step needs a valid database_id in wrangler.toml. A placeholder breaks the build. The ID is a read-only identifier (not a secret), so it's safe to commit.

Tech Stack

The technologies powering HackFinder

Built By

RD

ReproDev

Full-stack developer, hackathon enthusiast, builder of things.

See my full portfolio at khurramnazir.com and hackathon projects at codingagents.fyi

Past Hackathon Projects

A few things I've built at hackathons

View the Code

The full source is open on GitHub. The git history shows the development progression commit-by-commit — from initial scaffold through final polish.

View on GitHub