Zerbs was running two disconnected systems to manage his challenge: a generic Streamlabs spin wheel with no memory of completed survivors, and a static OBS overlay he manually crossed out by hand, with no way to undo a cross when a run failed. Every spin, completion, and reset was manual admin, done live, with chat watching.

I designed, built, and deployed the whole thing solo, working directly with Zerbs to clarify rules and edge cases. But this project had a second purpose: I wanted to test, in a real and time-pressured context, what AI-assisted development actually makes possible for a designer who can't write production code from scratch. Two days, one real user, one real deadline; no safety net of "it's just a demo."

There wasn't a traditional discovery phase; the timeline was two days. I watched Zerbs' streams, noted where he struggled live, and asked him directly about rules and edge cases. One moment shaped the whole design: chat kept asking how many times Zerbs had failed at a given checkpoint, and he had no way to answer without scrolling back through a spreadsheet. That single repeated question became the seed of the failure-tracking model.

Visual identity native to the game's world

DBD's language is fog, darkness, and dread, with survivor portraits as the primary asset. I leaned into that: deep void backgrounds, ember particles, a blood-moon atmosphere layer, and red/orange accents pulled from the game's palette. The goal wasn't to replicate DBD's UI, but to feel native to it.

Checkpoint and failure as core design, not an edge case

The challenge has a checkpoint mechanic: every 10 escapes locks in progress. I designed the data model around three states (pass/fail/in progress) with timestamps and attempt counters, so a failed run automatically rolled back to the last checkpoint in one click. No manual editing, no OBS fiddling.

The randomiser as an event

Survivor selection needed to feel like a moment, not a dropdown. I built a roulette animation that cycles through portraits before locking with a celebration beat: a shared moment between Zerbs and chat, not just an admin action.

Designed for the audience, not the admin

The primary view was the live overlay itself: large status, minimal text, high contrast, legible at a glance on stream. A leaderboard came later, limited to streamers, ranked by completion time and failure count, with VOD-linked proof of progress to keep it trustworthy.

This was built with AI-assisted development (Kilo Code), but "AI-assisted" undersells what was actually required. I skipped traditional design tools entirely. I drafted skeleton wireframes by hand, then described each interface element and its purpose to the AI, directing every structural and architectural decision. When persistent state turned out to need a server-side API route (browsers can't write to the filesystem), I worked through that architecture and debugged the implementation directly. I wasn't reviewing screenshots. I was in the code, treating the AI as a collaborator I had to direct and check, not a black box I could fully trust.

The first version shipped with real problems. SQL queries weren't optimised and buckled under load. Multi-tenant data isolation was weak; one user's data could bleed into another's view. There were SQL injection vectors in user input. Within days, the login endpoint took a brute-force attack.

I patched the SQL optimisation and tightened data isolation, using multiple AI agents as a review pass on the fixes rather than relying on my own read alone. For the brute-force attack, I enabled Cloudflare bot protection and rate-limited the login route. The leaderboard and the more polished version came after the core was stable, not before.

This is the part of "test and learn" that matters most: moving fast with AI-assisted development means you can ship something real in two days, but it doesn't remove the need to understand what you shipped well enough to fix it under pressure.

The tool went live on Zerbs' stream without announcement. Chat's reaction was immediate: "OH WOW," "THATS SICK," "W to whoever made that." The OBS overlay never came back.

“OH WOW”

“omg wowww”

“FIREEEEE”

“THATS SICK”

“SO ORGANIZED”

“W to whoever made that”

What started as a single-user tool running off a local file is now a multi-tenant web product with its own database backend. Over 5,000 users have tracked more than 300,000 games. It includes a public leaderboard, a second "Killer Gauntlet" mode with its own rules, cross-device access, and onboarding for new users who don't have Zerbs' context.

• Write automated tests during the initial build, not after bugs appear in production
• Run security and load testing before launch, not in reaction to an active attack
• Use git properly from day one, so failing changes can be reverted without destabilising the build
• Take a more spec-driven approach so changes stay concise and isolated
• Map the longer-term feature roadmap with Zerbs upfront, so things like the leaderboard are planned rather than bolted on