Auto-E2E

The missing layer of end-to-end testing

Everyone is building another place to keep E2E tests. Nobody is building the map.

Know what your product does and how its features depend on each other, and the E2E tests fall out — in Playwright, Selenium, Cucumber, or instructions for an AI with a browser.

Get early access How it works

The map · hover or tap a feature

changeddragged alongprerequisite
This is the thing nobody keeps today. Every test in the product hangs off one of these nodes; change a node and the map already knows which scenarios to re-check.

Why it is different

Start from what the product does, not from what the test clicks

Today's tools The product lives in 2–3 heads someone clicks Recorded clicks or AI-written steps generate · heal Test files become the only spec ✗ break when a button moves This project owner corrects The product code · docs · owners Feature map what it does + depends on Scenario tree how it's used, per feature Tests, any form playwright · selenium · …
Recorders, generators and self-healing locators all start from the click. They are ledgers of tests. The question of which tests, and why, stays in the heads of the two or three people who know the product.

Explore

The whole idea in four pages

The problem

The spec lives in two or three heads, the Playwright script became the record, and feedback arrives at the release.

Read →

How it works

Five layers — features, flows, scenario trees, tests, a readable view — and the three engines that keep them in sync.

See the diagrams →

For product owners

A scenario tree you can actually read, with the decisions waiting on you — no test code on screen.

See the tree →

Want this on your product?

We are building the first version with a handful of teams. Tell us what you test with and what breaks.

Get early access See how it works