D&D Play Companion
I designed and directed the build of a mobile-first play companion for D&D Beyond, turning characters built in DDB into a calm, thumb-first sheet you can play from at the table. The real work was method: solo on a one-week runway, I directed an agentic AI build process to ship it fast without ever silently getting the 5e rules wrong.
Role
AI Product Designer & Strategist
Industry
Consumer / tabletop-gaming tools
Team
Solo
Timeline
1 week, 2026
Problem
Built for building, not for playing
D&D Beyond is the system of record and a superb character builder, but it's desktop-shaped and tap-heavy to actually play from on a phone, mid-combat, at the table. Players needed a calm, glanceable, thumb-first surface for characters they had already built in DDB, without abandoning DDB or re-typing anything.
The bar was real adoption mid-campaign: it had to be faster than DDB-on-mobile and bridge from existing characters, or no one would switch. The constraints made that hard. DDB has no official API, browser CORS blocks direct calls, and its character JSON is component-based, so every final value has to be re-derived from the 5e rules. And it could not be silently wrong: a sheet that quietly miscalculates an AC or an attack is worse than no sheet, because trust is the whole product.
Process
Designed the decisions, directed the AI
The method was the point. From day one I directed an agentic AI build process: a written spec, a sixteen-task plan, then subagent TDD with a fresh AI implementer and an independent AI reviewer on every task, closing on one holistic review. I made every product and scope decision; the agents wrote the code and tests. The review ran at two altitudes, and the final holistic pass caught a schema bug the per-task reviews had each missed.
The product decisions served one outcome: a play surface, not another builder. It's mobile-first and glanceable, with core combat stats pinned in a sticky header and state as the single source of truth, so AC derives from equipped armour, never a number you maintain by hand. Where the 5e rules outran what I could safely model, I parked the gap as an honest import note rather than compute it wrong.
And rather than replace DDB, I imported from it: no API, so character JSON comes via a bookmarklet, the lossy PDF path rejected, mapped by a pure function that keeps the raw JSON.
Outcome
Adopted at a real table, not just shipped
The headline outcome is the build itself. Directing AI agents, I took the app from a single hard-coded demo to a tested, deployed, mobile-first product in about a week: a sixteen-task plan, twenty-nine passing tests, and three real bugs caught by the independent review loop before they ever reached the table.
And it's real, not a prototype. Around ten players in my group now run it in live sessions, importing any of four supported classes in under a minute, where before they hand-entered everything. Just as important, nothing is silently wrong: unknown cases surface as honest notes instead of bad numbers.
1 week
Solo, AI-directed: spec to deployed app
3
Bugs caught by an independent AI review loop before ship
10+
Players running it in live D&D sessions
Reflection
Review altitude beats review volume
The agentic build process is what made this possible: a spec, a task plan, and an implementer-plus-reviewer loop on every task let one person ship a tested, correct app in a week. The sharpest lesson was review altitude. A schema bug slipped past every per-task reviewer and only the final holistic pass caught it, so I now treat zooming out to review the whole as a distinct, non-negotiable step, not a nicety.
The build also showed me where the hard problems actually live: the auth wall and a hidden spell-system scope were the real work, not the UI. If I take it further, the leverage is in the data and the pipeline rather than more surface features.