The First Real Decision in a Multi-Agent Hackathon Build Wasn't About Agents

The Band of Agents hackathon build: one AI agent drafts a PRD, a second builds it, a third reviews the pull request, a fourth pulls in a specialist model when something looks sensitive enough to need extra eyes. Four agents working a pipeline that used to take four people.

The first real decision wasn't about agents or prompts. It was about a database.

Supabase was already maxed out across other projects, enough that adding one more would have meant fighting my own existing builds for capacity mid-hackathon. Convex looked tempting on paper: modern, well-documented, built with exactly this kind of agent-driven workflow in mind. But it uses its own database model, different enough from relational SQL that using it well meant actually learning it first. Learning a new database model the same week as a deadline was exactly the kind of risk worth skipping entirely, no matter how good the tool looked from the outside.

Neon won because it does the unglamorous things well: official MCP support so agents can read and write directly instead of going through an intermediate API layer, a real SQL console for debugging at 11pm, tight Vercel integration that meant one less deployment detail to get wrong under time pressure.

Once that call was made, the PRD came together fast: a dark dashboard pulling color cues from Band's own lime-green-and-indigo palette, the tables and build steps above mapped before writing a line of code. Step one shipped same day: Next.js scaffold plus the Neon schema, live and verified before I moved on to wiring the first agent.

The flashy piece of a build like this is the multi-agent pipeline, four agents handling work that used to take four people. That's the part that makes a good demo. The boring piece, the infrastructure choice, is what keeps that pipeline from falling over the night before the demo actually happens. Nobody in the audience sees which database you picked. Everyone notices when the app breaks because the one you picked couldn't keep up.

If you're choosing infrastructure under real time pressure, weight the boring criteria higher than usual: what already has tooling for the exact thing you need, what you can debug at 11pm without reading new documentation first, not what would be the most interesting thing to learn that week.