Flash Flood | Devpost

Inspiration

Every project we've shipped had the same awkward moment: the first real user finds the bug within thirty seconds. They paste a coupon twice, tab through a form with the keyboard, or give up on a page that loads too slowly. User testing needs users, and you don't have users until you launch. We wanted the opposite of a slow trickle of feedback after launch: a sudden flash flood of testers before it. They should be different kinds of people, each with their own patience, reading style and concerns, and they should use your site in real browsers while you watch.

What it does

Flash Flood is user testing before you have users. You enter a website you're authorized to test and pick a crew. Flash Flood gives each crew member its own real cloud browser on Browserbase.

Pick your crew. There are five one-click specialists: UI/UX, Security & privacy, Accessibility, Loading & performance, and Content clarity. Each comes with concrete checks and a preset read-only mission. You can also build custom personas with their own character, reading style, patience, quirks, goals and success criteria.
Watch the wall. Every agent gets a live browser window on a shared wall. A pixel-art surfer in the corner paddles while the agent works and sits idle when it isn't, and a speech bubble narrates its latest action. A queued agent shows a placeholder, never fabricated footage.
Read the evidence. Reports group findings across agents. They show per-agent criteria results and timelines with cited observations and screenshots. They also list which cohorts were tested and which were not. Exports are available as JSON or Markdown.
Know what actually happened. A timeout, an exhausted budget, a persona that ran out of patience and a real bug on your site are all reported as different outcomes. Natural-language criteria are labelled as heuristic judgments with checked citations, not as proof.
Practice targets included. A synthetic gift store has six planted bugs you can switch on and off independently. A structurally different project board is also included. With both you can see what the crowd catches, rerun after a "fix," and compare.

How we built it

App: Next.js 16 (App Router), React 19 and TypeScript 6, styled with plain CSS design tokens. The UI calls a thin owner-scoped API. No browser is ever launched inside an HTTP handler.
Worker: A separate long-running Node process owns all agent execution. It uses fenced leases, crash reconciliation and cancellation. A durable spend ledger reserves browser-seconds before anything paid happens.
Storage: node:sqlite in WAL mode with append-only migrations, plus a private artifact directory for screenshots and evidence. Zod contracts are shared between client, API and worker.
Browsers and models: Browserbase cloud sessions are driven by Stagehand v4. Inference is routed through Browserbase's Model Gateway, so there is no second provider key. Stagehand v4 removed its built-in agent(), so we wrote the persona loop ourselves. Each step observes the DOM and a screenshot, picks from the measured visible actions and adds in-character commentary. The loop tracks patience and stalls, and it checks criteria against what was observed.
Managed path: A second execution path uses Browserbase's Agents API. It has its own queue and tables, and it shares the same global eight-agent ceiling as the first path.
Live views and replay: Live-view URLs grant browser access, so they are served only through an owner-authorized endpoint and embedded in sandboxed frames. Session recordings play back through hls.js behind a same-origin protected adapter.
Testing: Over 3,000 offline vitest tests and 140+ Playwright E2E tests run with zero cloud calls. Every paid integration script requires an explicit --confirm-paid.
Process: We built in sequential layers, one PR per layer. Every PR used a mandatory template and got a rubber-duck review. A capability audit maps every claim to an implementation and a test.

Challenges we ran into

The platform moved under us. Our hardened native path for arbitrary public sites validates the exact browser build before trusting a session. Browserbase rolled to Chrome 153, and we had validated 145. Three genuine hosted attempts stopped at our own bootstrap check before a single observation. We did not bypass the guard. On the final day we pivoted the demo to the Managed Agents API, and we kept the native path intact and honest about its status.
Every second costs money. A crowd of cloud browsers can burn credits fast. We built a spend ledger with reservations and lifetime caps, plus a rule that an unknown launch outcome holds its budget and is not automatically retried. A lost HTTP reply never launches a second paid run.
Prompts aren't enforcement. On the managed path, scope and read-only instructions are only prompts to the agent. They are not network-level controls. We had to design the product and its copy around what we could actually guarantee, so public targets stay restricted to operator-approved origins.
Telling failure modes apart. "The agent didn't finish" can mean the site is broken, the persona got impatient, the budget ran out, or the infrastructure failed. Keeping those distinct from the worker through the reports took far more work than the agent loop itself.
Cleanup you can prove. A cancellation request is not proof that a browser was released. The worker independently re-checks each session before claiming closure, and the wall keeps showing unresolved cleanup after a run ends.

Accomplishments that we're proud of

A real crowd runs end to end. You launch from the UI, agents work in real cloud browsers, a live wall shows them, and a persisted report backs its findings with evidence.
Every hosted session we opened was independently verified closed.
The report refuses to overclaim. Criterion results have five states instead of pass/fail, counts come with denominators, and "absent on rerun" is never reported as "fixed" without confirming coverage.
A 3,000+ test offline suite makes the whole system checkable without spending a cent.
When the platform broke our main path, we pivoted in a day. We did not weaken a single safety check to make the demo work.
The surfers on the wall make people smile, and that matters.

What we learned

Getting an agent to click around a website is the easy 10%. The other 90% is leases, budgets, cleanup, evidence and honest reporting, and that part is what turns a cool demo into something you'd trust with your site and your credit card.
A prompt is a request, and only an enforced control is a guarantee. Be explicit about which one you have.
Pin and verify your platform assumptions, because hosted browsers update without asking you.
Personas are most useful for the difference between them. The keyboard-only user and the impatient user fail in completely different places on the same page.
Writing down what's not supported is a feature. It made our decisions faster and our demo more credible.

What's next for Flash Flood

Prove network-level egress enforcement so that any site you own can be tested, not just operator-approved origins.
Re-validate the native path against current hosted Chrome builds and add version-drift detection.
CI integration, so that every preview deploy gets flooded and the report is posted on the PR.
Extend automatic bug reproduction and path reduction beyond the one controlled coupon scenario to general findings.
Real accounts and multi-tenant hosting. Today it's single-host, with owner cookies and an access code.
Bigger crowds, richer persona libraries, and scheduled reruns that compare results over time to catch regressions.
Inspiration: I wrote this from the product pitch because I don't know the team's real origin story. Replace it if you or Sacha have one.
Test counts: "Over 3,000" vitest and "140+" E2E come from the last gate run recorded on this branch (3,198 and 141). I did not re-run the tests today.
Live windows: "Watch the wall" describes live windows as working. The code is on fayzan-managed-live-windows, but hosted rendering has not been proven yet. It still needs the paid five-agent rehearsal. If that doesn't happen before you submit, change the sentence to "a live wall tracks each agent's status and progress."