US$500 in credits at sign up →

Catch bugs before your users do.

Zerocheck is an AI QA engineer that tests your app end to end. Verify critical flows and find bugs with a prompt.

Write tests in plain English

discount-code.yamlzerocheck/tests
1version: zerocheck/v1
2name: Discount code reaches confirmation
3blocks_merge: true
4steps:
5 - Navigate to /cart
6 - Enter "SPRING20" into "Discount code"
7 - Click "Apply"
8 - Verify text "Discount applied" is visible
9 - Enter "4242424242424242" into "Card number"
10 - Click "Place order"
11 - Verify text "Order confirmed" is visible
npx zerocheck run --env stagingexit 1

Verify before deploy

staging

Checks running

Environment staging · Browser local

  • Signup creates a workspacePassed
  • Discount code reaches confirmationFailed
    1. Navigate to /cart
    2. Enter "SPRING20" into "Discount code"
    3. Click "Apply"
    4. Verify text "Discount applied" is visible
    5. Enter "4242424242424242" into "Card number"
    6. Click "Place order"
    7. Verify text "Order confirmed" is visiblePage showed "Payment declined"
  • Invite a teammateCould not complete

    configuration · No login steps for the admin account on staging

Your coding agent writes the tests, runs them and reads the results.

Tests are plain YAML files in your repository. Any agent that can edit a file and run a command can add a test, run it with the CLI and read the run record.

Works with

  • CLI
  • Web app
  • VS Code
  • Cursor
  • Claude Code
  • Codex
  • GitHub Copilot
  • Amp

Coding agents write code quickly. Someone still has to check the app works.

Unit tests and code review cover a lot, but they won't tell you whether a customer can still sign up and pay. That check usually falls to whoever has time to click through staging, or to a browser suite someone has to keep up.

No QA team? Here’s how to share the testing work and where to start with browser tests.

60-70%

of testing budget goes to maintaining brittle tests.

World Quality Report

40+ hours

of manual testing to run Lucid's regression each release.

Lucid Engineering

Browser tests your team can read, run and debug.

You say what should work. Zerocheck drafts the steps, runs them in a real browser and keeps what it saw.

Write tests in plain English

Paste a checklist or describe a flow. Zerocheck drafts each test and runs it before you review.

staging
release-checklist.md3 checks

Turn these checks into tests.

Drafting tests

  1. Signup creates a workspace

    5 steps · /signup

    Not run
  2. Invite a teammate

    4 steps · /settings/members

    Not run
  3. Export a report as CSV

    3 steps · /reports

    Not run
ValidateSave tests

What would you like to test?

Bulk upload tests

Run locally and in CI

Run from the web app, or with the CLI on a laptop or in a CI job you write.

staging

Your tests

2 of 4 selected

  • Signup creates a workspace
  • Invite a teammate
  • Export a report as CSV
  • Upgrade to the Pro plan
Run suiteAdd tests
CI jobci runner
$ npx zerocheck run --env staging
running…required check passes

Self-healing as your product evolves

A heal is saved only after the whole test passes, so a real regression still fails.

staging

Update billing details

staging · hosted browser

  1. Navigate to /settings
  2. Enter “billing@acme.example” into “Billing email”
  3. Click “Save changes”Not in the footer, where the last run found itFound again from the step’s description, in the header
  4. Verify text “Settings saved” is visible

staging.example.com/settings

Settings

Save changes

Billing email

billing@acme.example

Last runSettings saved
Running step 3…saved only after the whole test passed

Know if your app broke or the test couldn’t run

Bugs fail the test at the step that broke. Setup problems are marked Could not complete, with the reason.

Terminal~/acme-app
$ npx zerocheck run --env staging
running…
Failed

Your app broke

FAIL in the CLI: a check failed at the step that broke, with the page it saw.

Could not complete

The test couldn’t run

ERROR in the CLI. Fix the setup, not the app.

Bugs caught by Zerocheck

Catch them before they reach production. Nobody writes or maintains a script.

Check before merge

Discount accepted. Full price at checkout.

A shopper applies SPRING20 to a $100 order. “Discount applied” appears, but the total stays at $100 instead of $80.

Impact

Shoppers are asked to pay more than promised.

Check before launch

Quote form rejects a completed request

A buyer finishes the quote form and clicks Submit. “Complete all required fields” appears, even though nothing is missing.

Impact

An enquiry is blocked just as the buyer is ready to talk.

Check before deploy

Signup stops at email verification

A new customer submits the signup form. The page stays on “Sending verification email,” with no way to continue.

Impact

New customers cannot finish creating an account.

Check before merge

Upgrade confirmed. Pro features still locked.

A customer chooses Pro and sees “Upgrade successful.” When they reopen the account, it still says Free.

Impact

The features they upgraded for remain locked.

Check before release

Next page drops the active filters

A shopper filters for in-stock items in their price range. On page two, sold-out items and products over budget appear again.

Impact

Shoppers have to narrow down their results all over again.

Check in staging

Removed admin access still works

A teammate’s role changes from Admin to Viewer. After signing back in, they can still open restricted billing settings.

Impact

Former admins can still view restricted billing details.

How it works

We set up your first tests with you, on your own app. From there, your team adds tests, runs them from the web app or CLI, and reads the results.

01 We set up your instance and first tests with you

setup

You book a call and bring a flow you care about. We provision a dedicated instance for your team and set up your first 3–5 tests together. Those are where you start, not a limit. You leave with the instance URL, its access password and tests that have run against your app.

02 Describe a flow and see what happened

plain English

Describe a user flow (or paste your release checklist) and its expected result in plain English. Keep the steps and assertions in YAML files the team and any coding agent can add to.

discount-code.yamlzerocheck/tests
1version: zerocheck/v1
2name: Discount code reaches confirmation
3blocks_merge: true
4steps:
5 - Navigate to /cart
6 - Enter "SPRING20" into "Discount code"
7 - Click "Apply"
8 - Verify text "Discount applied" is visible
9 - Enter "4242424242424242" into "Card number"
10 - Click "Place order"
11 - Verify text "Order confirmed" is visible

03 Start a run locally or in CI

~1 min

One command on your laptop or in GitHub Actions, or run it in a hosted browser from the web app.

Terminal~/acme-shop
$ npx zerocheck run --env staging

04 Verify before you merge or deploy

every PR

Make the tests a required check: a blocking failure exits non-zero and stops the merge, and the same tests run against staging or production before you deploy.

Arni Mittal
Arni Mittal
Founder, Zerocheck

Why I built Zerocheck.

I spent years watching the same thing happen across teams. You add Playwright tests. A redesign breaks a good part of them, nobody has time to fix the selectors, and the failing ones get commented out. Six weeks later, production breaks. Those tests failed because they depended on selectors that changed during the redesign.

Zerocheck starts from the checks your team already trusts. Each one becomes a plain-English test with a real result. When the UI moves, the test finds the new target and shows you what changed. When the flow breaks, you get the step that failed.

Book a call and I’ll set up your first tests with you, on your app.

What your team will bring up

“We already have Playwright or Cypress tests.”

Good, keep them. Zerocheck is most useful for the flows they don’t cover, often the ones someone still checks by hand before a release. It doesn’t convert or replace your existing suite.

“Our CI is green. What would this catch?”

Things that only show up in the running app: a CSS change that hides the buy button, a discount that’s accepted but never applied, a form that rejects valid input. If someone on your team still clicks through staging before a release, that’s the run to start with.

“Won’t AI-run tests be flaky?”

It’s a fair worry. Steps like navigating or checking for exact text don’t depend on AI, and later runs reuse the controls a passing run already found. If a temporary error is retried and the test then passes, the result is labelled flaky, so it never looks like a clean pass. A failed outcome is never retried into a pass.

“Can’t we use a coding agent with Playwright MCP?”

For exploring a change, yes. What you don’t get from that session is a saved test anyone on the team can run next month, with a record of what happened each time. That’s what Zerocheck keeps.

Frequently asked questions

Getting started

Running tests

Cost

Data and safety

Bring the flow you click through by hand. It becomes your first saved test.

US$500 a month for a dedicated instance, with US$500 in credits at sign up. Month to month, cancel any time. See pricing