Playwright is a great driver. The suite is the expensive part.
Kery uses Playwright under the hood, so this is not a case against it. It is a case against maintaining hundreds of selectors for flows that change every sprint.
Nobody abandons a suite because writing it was hard
The first twenty tests are fine. The problem arrives in month four, when a redesign moves half
the selectors, three tests start failing for reasons unrelated to the change that triggered
them, and somebody adds test.skip to unblock a release.
From there it is a familiar slide: the suite is red more often than it is right, people stop reading it, and the coverage you paid for stops meaning anything. The flows that actually break in production are usually the ones that were never covered — settings, permissions, empty states, the mobile layout, the feature added last sprint.
The gap Kery fills
Not the tests you wrote. The tests you meant to write, for the change you shipped on Tuesday, which nobody had time to cover.
Derived from the diff, not from a fixture file
- It reads the pull request. The diff, the title, the description — enough to infer what the change is claiming to do.
- It signs in. Form login, Clerk, Supabase, Auth0, Firebase, 2FA codes, magic links, Vercel preview protection.
- It walks the flow in a real browser on the preview deployment for that PR.
- It posts a verdict with video, seeking straight to the moment that decided the result.
- It gets quieter over time, remembering your app's paths, conventions, and the findings you have called false positives.
Nothing to keep in sync, because nothing was written down. When the flow changes, the next run reads the new flow.
Written suite vs. derived checks
| Hand-written Playwright | Kery | |
|---|---|---|
| Time to first check | Hours to days per flow | Minutes — connect the repo |
| Maintenance | Selectors, fixtures, waits | None — re-derived each run |
| Coverage | What you had time to write | Whatever the diff touches |
| Determinism | High — same steps every run | Lower, so only contradictions gate merges |
| Auth setup | Storage state, fixtures, secrets | Configured once per environment |
| Failure output | Trace and stack | Video, logs, and repro context on the PR |
| Best at | Critical paths that must never regress | The long tail nobody covered |
When you should keep writing Playwright
A deterministic suite still wins where the check must be identical every time: payment authorisation, a signup funnel with revenue attached, a compliance path, anything you would want to bisect across a hundred commits. Written tests are also faster and cheaper per run.
Run both. Playwright pins the handful of flows that must never move; Kery covers everything else, on every pull request, with no suite to keep alive.
Playwright and Kery, side by side.
Is Kery a replacement for Playwright?
No, and it is built on Playwright. Kery replaces the work of writing and maintaining a suite for flows you were never going to get around to covering. Deterministic critical-path tests that you already own and trust are worth keeping.
Why not just write more Playwright tests?
Because the cost is not writing them, it is maintaining them. Selectors drift, flows change, and a suite that goes red for the wrong reason gets muted within a month. Kery re-derives what to check from the diff each run, so there is nothing to keep in sync.
Do I need to remove my existing test suite?
No. Most teams keep Playwright for the handful of flows that must never regress and let Kery cover the long tail — the settings page, the empty state, the mobile layout, the flow someone added last sprint.
How does Kery handle flakiness?
Kery only fails a build on a contradicted check — a claim in the diff that the browser run actively disproved. Everything else is reported rather than enforced, so an ambiguous result does not block a merge.
Can Kery run in my existing CI pipeline?
Yes. The open-source engine runs in your own pipeline with Docker, and Kery Cloud runs pull request checks against preview deployments without any workflow configuration.
Which browsers does Kery run?
Real Chromium browser sessions driven through Playwright, including mobile viewports.
Put proof in every pull request.
Connect a repo and Kery starts checking pull requests against their preview deploys. No test scripts, no CI config.