The room convenes a panel of five distinct AI user personas
Each persona delivers a reaction and a willingness-to-use score
The verdict, three riskiest assumptions, and one test to run next

Reckoning Room

Stress-test your product idea against a panel of evidence-grounded AI users before you build a single screen.

Paste an idea in plain language, optionally name a target audience, and hit Convene. The room assembles five distinct AI user personas who each react in character: what they would love, where they get confused, the one objection that would stop them paying, and a willingness-to-use score. Then it synthesizes the panel into a single verdict (build, refine, or rethink), surfaces the three riskiest assumptions your idea depends on, and hands you one concrete test to run with real people next.

We built it for World Product Day: Everyone Ships Now. The whole point of the hackathon is to ship fast with AI but keep the feedback loop alive. Reckoning Room is the front of that loop: red-team the idea before you write code, then go measure what you shipped.

Inspiration

We kept watching people, ourselves included, pour a weekend into an idea before ever checking whether anyone wanted it. The slowest, most-skipped step in shipping is validating against real users, so we built the gut-check we always wished we had. World Product Day is about shipping fast with AI but keeping the feedback loop alive, and that is exactly the gap we wanted to close before the first screen gets built.

What it does

You paste a product idea in plain language and optionally name a target audience. Reckoning Room convenes a panel of five distinct AI users who each react in character: what they love, where they get confused, the one objection that would stop them paying, and a willingness-to-use score. It then synthesizes a build, refine, or rethink verdict, the three riskiest assumptions the idea depends on, and one concrete test to run with real people next. It is for PMs, indie founders, and designers who want a fast, structured red-team before committing build time.

How we built it

It is a single-page Next.js 14 app with TypeScript and Tailwind, on a hand-built shadcn-style component layer so there is no heavy runtime. One Node API route fans out a parallel Gemini 2.5 Flash call per persona, each pinned to a distinct archetype, then runs a single synthesis call on Claude Sonnet when a key is present or Gemini otherwise. Keys live in localStorage and are passed as request headers, and the whole thing degrades to a seeded, idea-aware demo panel when no key is set.

Challenges we ran into

The hardest problem was stopping the panel from sounding like five copies of the same agreeable AI. We solved it by pinning each persona to a separate archetype and stance and forcing at least one hard dealbreaker per voice. The second was keeping a live demo unbreakable: parallel calls plus a graceful fallback to a tailored demo panel means a bad key or a rate limit never shows a broken screen.

Accomplishments that we're proud of

We are proud that the honesty is the product, not a disclaimer. Every persona claim carries a reasoning-basis tag so you can tell a stated need from a demographic guess, and the output is assumptions to validate, never a fake success score. The reveal is genuinely fun too: personas walk in one by one like a focus group, which lands the wow in seconds.

What we learned

Synthetic users are sharp at surfacing objections and comprehension gaps and weak as success predictors, so the right move was to constrain them hard and frame everything as a red-team. We also learned how much craft a no-login, instant-value flow takes: most of the work was prompt design and graceful fallbacks, not backend plumbing.

What's next for Reckoning Room

Persona memory so you can rerun a refined idea against the same panel and see what changed. Letting users save and compare verdicts across iterations. A deeper panel-tuning step with custom demographics. Exportable test plans for the suggested next experiment. And wiring the shipped product into Novus so the loop closes end to end: validate before build, then measure after ship.