FormCrash Lab

Break critical user journeys on purpose. FormCrash replays real flows, injects deterministic failures, and proves recovery with before-and-after evidence.

Comment

Inspiration

I started FormCrash Lab during OpenAI Build Week after exploring several developer-tool ideas.

The problem I kept returning to was timing-dependent bugs: a user clicks submit twice because the first request is slow, retries an important action, refreshes at the wrong moment, or continues interacting while an earlier request is still processing.

These failures do not always crash the application. Instead, they can create duplicate orders, duplicate payments, inconsistent records, or an interface that appears successful even though a request failed.

My initial direction was too broad. I started building around browser recording, replay, and general failure testing, but the project gradually became a complicated Playwright dashboard without a clear product thesis.

I eventually narrowed it down to one question:

Can I reproduce a failure around an important user action and clearly prove that the same problem no longer happens after it is fixed?

The project became more convincing when I tested recorded journeys from my own SaaS application. FormCrash exposed real problems in several flows that I had not noticed during normal manual testing.

That was the point where it stopped feeling like only a hackathon demonstration.

What it does

FormCrash is a local-first, pre-production resilience-testing workbench for transactional browser journeys.

A developer can:

  1. Record a successful journey in visible, controlled Chromium.
  2. Save that journey as an immutable version.
  3. Confirm the Critical Action that creates or changes application data.
  4. Approve an Outcome Check that proves the action succeeded.
  5. Review FormCrash's recommended state-changing network request and assertions.
  6. Generate reusable double-click, triple-click, and delayed-repeat tests.
  7. Run those tests and inspect screenshots, request evidence, assertions, ordered events, and a final verdict.

FormCrash uses deterministic rules to rank network requests and recommend assertions. It does not require an AI model at runtime, and its recommendations remain explainable and repeatable.

The bundled checkout demonstrates the core workflow clearly. The vulnerable version creates duplicate orders when checkout is submitted twice. The fixed version prevents the duplicate using client-side locking and server-side idempotency.

How I built it

FormCrash is implemented as a TypeScript monorepo managed with pnpm.

The main components are:

  • A Next.js and React dashboard for Projects, Journeys, Tests, Runs, configuration, and evidence review
  • A Fastify control server that owns the Playwright browser and execution lifecycle
  • Visible Chromium automation for recording and replay
  • A bundled Next.js sample checkout with vulnerable and fixed modes
  • Shared Zod contracts between the dashboard and server
  • SQLite persistence for journeys, tests, runs, events, assertions, and screenshot metadata
  • Server-Sent Events for live execution progress and event replay

Recorded journeys, generated tests, and completed runs remain durable records instead of disappearing after a one-time automation wizard.

External application support required additional systems for authentication-state capture, runtime variables, generated test identities, sensitive-value masking, and transitive secret redaction.

Request recommendations are produced through deterministic scoring. FormCrash evaluates signals such as HTTP method, response status, request timing, origin, path similarity, repeated occurrences, and whether a request resembles analytics or background traffic.

Assertion recommendations are also derived from captured evidence, including successful responses, visible outcomes, error indicators, URL changes, and the state of the control being repeatedly triggered.

Challenges

The hardest problem was not controlling Chromium. Playwright already handles that well.

The difficult part was turning browser events, network traffic, screenshots, assertions, and warnings into a workflow a developer could understand.

One click can trigger the real API mutation, multiple read requests, analytics calls, and background refreshes. Requiring the user to manually inspect every request would defeat the purpose of Guided mode, so I added deterministic request scoring to recommend the request most likely associated with the Critical Action.

Assertions created a similar problem. Requiring developers to manually author every check would make FormCrash another test-script editor. The server therefore recommends assertions using evidence observed during the successful baseline journey.

Authentication was another difficult area. FormCrash can capture and restore browser authentication state, but reliability still depends on how the target application manages sessions, redirects, cookies, and login state.

The user interface also remains less polished than the underlying execution system. Some screens still expose too much technical information, and parts of the workflow require clearer guidance.

What I learned

The biggest lesson was that having a technically large project does not automatically make the product clear.

At one stage, FormCrash had many features, but I still could not explain why someone would use it instead of writing Playwright tests. I had to stop expanding the feature set and narrow the workflow to:

Critical Journey → Critical Action → Controlled Failure → Outcome Check → Before/After Proof

I also learned that deterministic automation can remove substantial manual work without requiring runtime AI. Request and assertion recommendations are generated from captured evidence and explicit rules, so identical evidence produces an explainable result.

Testing against my own SaaS was especially useful. Real applications contain authentication, redirects, changing data, background requests, and unpredictable interface states. Those tests demonstrated both where FormCrash is useful and where it remains fragile.

How I used Codex and GPT-5.6

Codex and GPT-5.6 were used throughout the project for product planning, architecture, implementation, debugging, test creation, and refactoring.

They helped me:

  • Break the initial architecture into verifiable vertical slices
  • Design the monorepo, contracts, execution lifecycle, and persistence model
  • Implement browser recording, replay, assertions, and evidence capture
  • Diagnose authentication, request-matching, navigation, and state-management problems
  • Design and test deterministic request and assertion recommendation systems
  • Review the product critically when it became too broad
  • Refactor the interface and workflow around Projects, Journeys, Tests, and Runs

I did not accept every generated direction unchanged. The most important human decisions were narrowing the product thesis, removing unnecessary directions, defining which evidence was safe to persist, and choosing deterministic recommendations instead of introducing a runtime AI dependency.

FormCrash was built with Codex and GPT-5.6, but the resulting application does not require an OpenAI API key or an AI model while running.

Accomplishments

The part I am most satisfied with is that FormCrash is no longer limited to a fake checkout demonstration.

It can record and replay journeys against another application, identify likely state-changing requests, recommend assertions, inject repeated interaction around a Critical Action, and persist the resulting evidence.

The bundled checkout remains the clearest before-and-after proof: the vulnerable version creates two orders, while the fixed version creates only one.

More importantly, I used FormCrash against workflows in my own SaaS and found actual problems. The project is not polished enough for general production use, but it demonstrated that the core idea is useful outside the bundled sample.

What's next

The most important improvements are:

  • Making authentication capture and replay more reliable
  • Simplifying the interface and removing unnecessary technical noise
  • Improving the organization of journeys, tests, and runs
  • Adding a clearer side-by-side comparison of vulnerable and fixed executions
  • Supporting delayed, dropped, and deliberately failed requests
  • Making local setup and external-project onboarding easier
  • Expanding deterministic diagnosis and recovery guidance

The current version proves the core workflow while making the remaining product and usability problems much clearer.

Built With

Share this project:

Updates