I had never taken part in a hackathon as a competitor before. I wanted to try it, and I wanted to put a team together. The team never happened. So I spent 24 hours working alone and shipped a product for venture funds in a niche I had never touched for a single day.
Here’s how it looked from the inside: what actually got built, what it cost me and what’s worth taking away if you’re planning to build something on your own.
How I ended up there
A friend told me about the Hack-Nation 6th Global AI Hackathon. It runs under the MIT Club of Northern California and the MIT Club of Germany: 5,500 applications, participants from 125 countries, people from 600+ universities, more than 2,000 at the starting line. Six sponsor challenges, 24 hours to build a prototype, a prize pool starting at $35,000 plus API credits.
The plan was simple: the two of us go in, pick up a couple more people, end up with a real team. It fell apart at registration. Her invitation email with the access code never arrived, and without that code you can’t get onto the platform. The problem turned out to be widespread: several people reported the same thing in Discord. The organizers handle these cases by hand, and hers wasn’t resolved before the start.
After that I looked for a team on my own, in the challenge’s Discord channel. A lively marketplace ran there the whole time: people dropping intros, LinkedIn links, pitching you to join them. Something like 15 teams had signed up for my challenge before the start. I ended up solo.
Getting ahead of myself: going solo turned out to be a fairly common choice at this hackathon.
The challenge: The VC Brain
Challenge two, sponsored by Maschmeyer Group. The brief: build an AI-first operating system for a venture fund that lets you make a well-grounded decision on a $100K check in 24 hours instead of several weeks.
It sounds like “yet another startup screening tool,” but the whole point sits in the details of the brief.
Here’s how the sponsor frames the problem: the best founders often don’t get funded, not because the idea is weak, but because nobody with a checkbook knows about them. Their story is smeared across pitch decks, repositories, half-finished websites and posts nobody reads closely. Classic due diligence is weeks of calls and references: economics that don’t work on a $100,000 check. Capital flows through connections rather than merit. And early teams are invisible to existing venture tools, because they aren’t in Crunchbase or Dealroom yet.
Hence the hardest and most valuable part of the task: how do you assess a founder who has no track record yet. Not filter them out. Assess them.
The judging rubric made the priorities explicit: data architecture and system intelligence 30%, investor value and execution 30%, analysis quality and trust 25%, interface 15%. In other words, a beautiful interface on top of mediocre data loses.
How to get up to speed in an unfamiliar niche in 24 hours
This is probably the most useful part of the experience, because it transfers to any task.
I knew venture capital at the level of general knowledge. Not a single day of practice. 24 hours to understand the domain more deeply than anyone who just read the brief.
What worked.
The primary source beats the summary. The challenge had a Q&A session with the sponsor. Those 90 minutes of conversation are the only place where they say what they actually want, as opposed to what’s in the general description. I pulled 55 separate statements out of it: requirements, scope constraints, pain points, scoring signals, facts about their process.
Knowledge has to be decomposed, not read. I ran the transcript and the research documents through my own pipeline, which turns meetings and documents into a structured base: every statement gets a type, an identifier and a link to its source. The output was a hundred-plus items across three batches, including 27 scoring signals and four recorded risks. The backlog was then built off that base. This isn’t about the tool, it’s about the principle: if you don’t break knowledge into addressable pieces, it stays a feeling rather than a basis for decisions.
Product invariants before code. The sponsor’s answers produced rules that couldn’t be broken even for the sake of simplification. For example: the three scoring axes are never averaged into a single number, because an average hides disagreement, and disagreement is the most interesting signal there is. Or: when data is missing, what goes down is the system’s confidence, not the founder’s score. Those rules stayed in front of me for the whole hackathon and killed half the “let’s just make it simpler” arguments.
Other people’s solutions as a map, not as code. I went through nine open-source projects in adjacent areas, not to copy them but to see what everyone does the same way. It turned out that almost all of them look at this only from the investor’s side and evaluate what’s already visible. Which means the differentiation sits exactly where nobody is working.
How current a signal is matters more than the list of signals. I checked separately which signals still mean anything in 2026. GitHub stars have long been a vanity metric. Having a prototype has lost its value, because a prototype now takes an evening. What’s left are the things that are expensive to fake: merged pull requests into other people’s repositories, reviewing other people’s code, showing up consistently over a long stretch.
By the time development started, I didn’t have ideas. I had recorded requirements with sources attached.
What actually got built
A product for a venture fund, four stages: sourcing, screening, verification, decision. Target segment: founders and startups at the earliest stages, with no track record yet, the ones existing venture tools structurally cannot see.
Two entry points, one funnel. This is the crux, and it usually gets lost when the project is summarized.
The first one is inbound: the founder applies themselves. The form is deliberately minimal: company name, email, deck. Nothing else is required, because an oversized form works against you: the people it filters out hardest are the qualified ones. The system then asks up to three optional questions, and they aren’t arbitrary. It computes which scoring criteria are fundamentally unreachable from public sources, and asks about exactly those. In our model that’s first customers, the specificity of the target segment and insider knowledge of competitors: together almost 30% of the founder score, and none of it visible from the outside. Any question can be skipped in one click.
The second one is outbound: a radar that finds people who haven’t applied anywhere yet. It scans public traces: GitHub, Show HN, personal sites. A founder profile gets created without a deck and enters the same funnel.
From there both sides are processed identically: an outbound find goes through exactly the same scoring as an inbound application. The point of outbound isn’t to invest blind, it’s to provoke a real application from someone who would never have found their way to a fund on their own.
Scoring across three independent axes: founder, market, idea-market fit. Each axis has its own trend. They never collapse into a single number.
Every claim verified separately. Revenue, traction, team background, market size: each claim is traced to a source and gets its own confidence level. Contradictions get caught before they reach the investor. The demo data has contradictions deliberately baked in, and the pipeline does find them.
Honesty as a feature. No data on valuation: the system writes “not disclosed” instead of making something up. A memo that flags its own gaps is more useful to an investor than a polished, confident one.
A founder score that travels with the person. It isn’t tied to a specific company, doesn’t reset when they start a new one and gets refined with every new milestone.
Access for humans and for agents. A web interface plus an API and a CLI, so the fund’s own agents can query the system directly.
The output: an investment memo and a check recommendation the investor can act on the same day.
The numbers at submission: 12 features, 75 commits, 22 n8n workflows, around 900 automated tests. Stack: Supabase (Postgres), n8n, OpenAI, Tavily, all in Docker, deployed on a VPS. The live chain runs from a founder’s application to a finished memo in 2.5 minutes, fully automatically.
How one person does this
The key decision: I didn’t try to write it all myself. Claude and Codex replaced the dev team.
The pipeline itself was completely standard, SDD: spec first, then plan, then plan review, and only then code. Nothing exotic, just held to all the way through.
The process for each feature looked like this:
- Spec. All the sources go in first: the internal requirements base, NotebookLM, Exa, my own RAG base and Telegram corpus, the breakdown of the nine other solutions. Then options, a choice, and a re-check of that choice against the same sources. The design doc goes into the feature’s folder.
- Plan. One agent writes it, another reviews it, and it cycles through fixes until an explicit APPROVED. This is the step you’re most tempted to skip for speed, and it’s the one that saves the most time.
- Parallel execution. Independent stages get picked up at the same time: separate agents for backend, frontend, database and deployment. Dependent ones run in sequence. The frontend always goes through a separate brief with frozen API contracts: that way the interface and the backend get built simultaneously instead of one after the other.
- A QA gate through Playwright. A dedicated agent opened the browser itself, ran the scenarios itself and issued a verdict. Without passing that gate, a feature didn’t count as done. This is what separates “seems to work” from “verified.”
- An execution tracker. A table of task, agent, status, result, updated by the orchestrator continuously. This is what lets you recover from any failure at any point.
I built the frontend in Lovable and Claude Design: generate the screens, then pull the sources into my own repo and polish them.
The rule was strict: no hands-on work in the main context. The main model only orchestrates: assigns tasks, merges results, holds the invariants. Some features ran in parallel terminals at the same time, and that’s exactly where the speed came from: a whole wave of independent features closed overnight.
What it cost
The honest part.
Lost work from parallelism. The same thing happened twice during the hackathon: several terminals were editing shared database schema files, and none of them committed those edits. One stray command in a neighboring window wiped out hours of work across three features at once. The only thing that saved me was that the objects were already applied in the live database, so the schema could be restored from there. If the container had been restarted clean before that, the work would simply have been gone.
The lesson that cost the most: shared files get committed in the same hour they’re edited. Not “at the end of the feature,” not “before submission.” The moment you have more than one agent writing to a shared file, uncommitted work is work that doesn’t exist.
More scope than time. Two of the 12 features never reached “closed.” Every closed feature still has known open items, which I wrote down honestly instead of pretending they weren’t there.
Submission is its own project. Three videos were required: a product demo, a technical one and a team story. Even solo, that’s three recordings. Plus a short description, a public repository and a code archive. You need to budget time for this up front, not in the last hour.
A platform-wide failure at submission. Some files didn’t make it through because of a technical problem on the platform’s side, and every participant had to re-upload their videos through a separate form. The finalist announcement slipped by a week.
What I’m taking away
Solo no longer means “I’ll get less done.” It means “everything comes down to how precisely you state the task.” Speed stopped being a function of how many hands you have.
The role shifted from executor to orchestrator. Decomposition, invariants, accepting the result. That’s exactly what a product manager does every day, except the cycle compressed from weeks to hours. My 16 years in product were worth more here than any coding skill.
An unfamiliar niche stopped being a barrier. It became a question of how well you work with sources in the first few hours. Whoever breaks the brief down into addressable requirements outruns whoever just read it.
Process discipline beats typing speed. Gates, trackers, plan reviews all look like overhead on a 24-hour sprint. In practice they’re exactly what kept things under control when five branches of work were running in parallel.
What’s next
No results yet: finalists are announced by July 30, with live pitches and the awards on August 1. I’ll share the outcome either way.
The project’s code is open: https://github.com/Serg1kk/the-vc-brain