Inspiration
- In 2026, people are adding AI to everything from cars to toasters. Hackathon projects are no exception. Almost every project today is built with coding agents like Codex and Claude, which means hackers ship exponentially more features, sometimes pushing tens of thousands of lines in a single weekend.
- The problem is that judges don't have time to read any of it. The actual implementation is completely abstracted away from them. They experience a project through a demo video and a README, and that's it.
- When we were brainstorming, we realized this was a real gap in hackathon platforms like Devpost (which, much as I love it, looks like it belongs in 2010 💔).
- Further hackathon projects are genuinely fun and informative to browse, but unless a project has a winner tag on it, it gets lost in an ocean of submissions. Devpost's UI doesn't help either. Discovery is basically nonexistent, so most of the work people pour a weekend into never gets seen.
- So we built Hack Stack: a platform that indexes every submitted project, sends an AI agent to explore the repos, and surfaces what's actually there.
What it does
Hack Stack indexes the codebases of all submitted hackathon projects and does four things:
- Verifies claims. It spawns an AI agent that reads the Devpost submission and README, extracts the list of claimed features, then clones the repo and explores the code to check whether each feature actually exists.
- Gathers analytics. It profiles both hackathons and hackers: the technologies, libraries, and frameworks used, which coding agents were involved, commit counts, and lines added or deleted.
- Exports to your agent. It lets you drop any project straight into your own local coding agent to dig in further.
- Makes discovery effortless. It puts everything in one accessible interface, so you can see every project and all the info you need at a glance, all in a single place.
How we built it
The analysis pipeline (the core)
- An ingestion layer clones each submitted repo and pulls in its Devpost submission and README.
- We spawn a Codex agent running as a full coding agent inside a sandbox, so it navigates the codebase the way a human would: reading files, following imports, and inspecting the implementation rather than skimming a summary.
- The agent extracts the list of claimed features from the submission, then verifies each one against the real code.
- These analysis agents are hosted on Trigger.dev, which lets us spawn and manage them independently per project.
Analytics and export
- An aggregation layer rolls individual project data up into analytics across an entire hackathon: technologies, libraries, frameworks, coding agents used, commit counts, and lines changed
- An export mechanism hands any indexed project off to your own local coding agent, so you can pick up exploration where Hack Stack leaves off on your own local agent (like Codex).
The stack
- Supabase (hosted Postgres) as our database. We designed all the schemas ourselves and had Codex implement them in TypeScript with Drizzle, but we manually reviewed every generated migration before applying it.
- Frontend in Next.js, React, and Framer Motion, coded with Codex while we made the design calls on look, feel, and layout.
- Trigger.dev to run our agent flows, spawning and managing the analysis agents independently per project.
- Hosted on Vercel, with the production database on Supabase.
How we used Codex
- Codex was our primary coding agent, and it wrote the vast majority of the Hack Stack codebase, with us directing the architecture, design, and review.
- Before writing any code, we wrote an
AGENTS.mdand aPLAN.mdso that both our Codex instances shared the same context about what we were building. This kept our agents (amongst the teammates) aligned instead of each one guessing at the project independently. - We worked in branches to keep the blast radius small whenever we let Codex build a feature. We also split staging (development) and production (main), with pushes to those branches gated to just us (i.e., Codex did not have access by default).
- We leaned on skills from Matt Pocock's skills repo, especially the
/grill-meskill, which interrogates our plan before any code gets written. Paired with plan mode, this made sure Codex was working from the same mental model we had when designing the project. - For the frontend, our workflow was heavily visual. We took screenshots of the site and pasted them into Codex to give it real context on what we were building. We also connected Codex to Browser Harness so it could debug itself in a loop: given a spec, it would open the browser on its own, screenshot the components it was working on, and iterate.
- We used specific skills to get Codex's help wiring up our hosting on Supabase, Vercel, and Trigger.dev.
- And yes, we used the Imagen skill to generate the cover image for this Devpost :p
Challenges we ran into
- Compute, compute, compute. Nearly every challenge we hit traced back to this.
- We were low on credits for most of the build (thanks for the free $100 Codex credits!).
- The indexing pipeline is compute-heavy and burns through tokens fast, so we had to be deliberate about where we spent them. We put three controls in place: approval gating on new projects, a hard cap on project count, and restricting the in-depth analysis agent's feature-detection runs to winner projects from older hackathons.
- We originally wanted to index most of Devpost, including older hackathons, so we could surface trends over the years (tech, libraries, frameworks, lines of code, and so on). We settled for a handful of the biggest recent hackathons instead.
Accomplishments that we're proud of
- We built the whole thing on a shoestring compute budget. Instead of just running out, we engineered around it with approval gating, project caps, and targeted analysis, so the product works within real constraints.
- We followed SWE best practices while moving at agent speed. Clean branches, staging/prod separation, and manually reviewed migrations meant we shipped fast without breaking a live database.
- We closed a real gap. Discovery and code-level insight genuinely don't exist on hackathon platforms today, and Hack Stack makes both effortless. We're honestly surprised no one has built this yet, especially the Devpost team themselves!
What we learned
- Agentic coding doesn't let you skip the fundamentals, it raises the stakes on them. When Codex is shipping features fast, good software design, git sanity, and CI pipelines matter more than ever, not less.
- Version control discipline is what makes the speed safe. Working in branches, keeping a clean history, and gating who can push to production is what let us move fast without breaking things.
- Real hosting has real consequences. We learned the split between local, staging, and production databases the practical way, and why you never point an agent at a live prod db and hope.
- Planning context upfront pays off, but you still have to review everything. This was most obvious with schema changes: we let Codex generate migrations, but every one got manually reviewed before it touched a hosted database with live data.
What's next for Hack Stack
- Indexing the OpenAI Build Week gallery. Once the gallery opens, we plan to index it so judges can browse those projects directly on Hack Stack. It's also the perfect chance to showcase Hack Stack live on real, current projects.
- Funding. Indexing every hackathon on Devpost takes serious compute, so growing the platform to that point will mean raising investment to cover it.
- Or... selling it to Devpost itself. 👀
- Agentic RAG for idea discovery. We want to embed every indexed project into a vector database and build a brainstorming tool for hackers. You'd enter a project idea, we'd embed it and run a similarity search across everything that's already been built, and surface how others approached the same space before you write a line of code, so you don't end up building something that already exists.
- Knowledge graphs and a chat interface. With more compute, we'd make the analysis agent sophisticated enough to generate in-depth architecture diagrams and knowledge graphs for each project (in the style of understand-anything). We'd pair that with a chatbot that has the full context of whatever project you're looking at, so you can talk directly to the analysis agent instead of reading its output. Compute limits are the only reason this didn't make it into the current build.
Built With
- cheerio
- codex
- css
- drizzle-orm
- github
- githubapi
- motion
- next.js
- node.js
- octokit
- postgresql
- react
- supabase
- trigger.dev
- ts
- vercel
- zod
Log in or sign up for Devpost to join the conversation.