How structured briefs turned a solo vibe-coding session into a shipped product with dependency chains, configurable workspaces, and live market data
I wanted to build a Bloomberg-terminal-style dashboard for prediction markets. Not just a price ticker. A real intelligence surface where you browse events by category, drill into matchups, build custom workspace layouts with drag-and-drop panels, and layer on context like weather forecasts, news feeds, and geographic maps.
The scope was big. Seven categories of events tracked across Kalshi. Configurable workspace pages with panel grids. Odds movement charts with multiple timeframes. Countdown timers for live events. A Cloud Functions backend proxying the Kalshi API with caching and series grouping. Auth, deployment, mobile optimization, search.
I organized it into 37 briefs across 4 sections: Foundation, Geo & News, Workspace Engine, and Monetization & Launch.
Every feature started as a brief before any code got written. Not a one-liner in a task manager. A structured spec with a description (the why), scope (verifiable deliverables), constraints (guardrails), and a decisions field that the agent updates as it works.
Here's a real one. The Workspace Layout Engine was the most critical brief on the board. It defined the panel grid system that the weather, news, maps, and event composition features all built on top of.
The core configurability layer that makes ArkOdds feel like a Bloomberg terminal. Users create pages (like workspaces/tabs), each containing a drag-and-drop grid of panels. Panel types include: odds table, hierarchical view, countdown, chart, map, news feed.
The agent reads this through Nexboard's MCP integration. It gets the full brief context, builds against the scope, and writes decisions back. The next session picks up where the last one left off. No re-explaining.
37 briefs don't exist in isolation. The Workspace Layout Engine couldn't start until Auth and the Odds Panel were done. And four downstream briefs (weather, news, maps, event composition) couldn't start until the layout engine was finished.
Nexboard tracks these dependencies explicitly. When a brief is blocked, you see it. When a dependency finishes, the blocked brief becomes available. I don't have to remember what depends on what.
ArkOdds launched at arkodds.com with 35 of 37 briefs shipped. The two remaining: a CI/CD pipeline (scoped, not urgent since I deploy manually) and a plan persistence bug (draft, found late).
Not 100%. That's the honest number. But 35 shipped briefs is a full prediction market dashboard with live data, configurable workspaces, and a Cloud Functions backend.
ArkOdds wasn't the only board I was managing. During the same period, I had 4 active boards: ArkOdds (37 briefs), Nexboard itself (72 briefs), TallyThat (22 briefs), and Who's Wrong (8 briefs). Over 130 briefs total, one developer.
That only works because every brief carries its own context. The agent doesn't need me to explain the app architecture. It reads the brief's scope, checks the decisions from previous sessions, and builds. Switch to a different board, different project, and it works the same way.
Every brief has a decisions field. It's a living log of what was built, what was tried, and what was decided. The next agent session reads it and picks up immediately.
The layout engine had to ship before weather panels could start. Nexboard tracks this. No guessing what's ready to work on.
ArkOdds, Nexboard, TallyThat, Who's Wrong. 130+ briefs. The dashboard shows all of them at a glance: what's blocked, what's in review, what to pick up next.
Boards