AI writes far more code, far faster, so the bottleneck is verification. QA Reef records a real browser workflow once, then runs that same flow four ways.
Free plan: 500 browser-minutes a month and $20 in signup credit · no card · nothing to install on your site.
Six things QA Reef does, playing out on a mock app. Not a video: the page is driving itself.
You drive once. It records every action and writes the Playwright.
Waiting for the agent…
Waterfront rooms above the old harbour
Quiet courtyard stay near Alfama
The outline builds as the agent works.
The app changed and the locator broke. It finds the button by what it says on screen.
Waiting for the agent…
Waterfront rooms above the old harbour
#book-btn not found#book-btn → role=button name="Reserve now"A 2004 portal with no usable selectors. It reads the screen and clicks what it sees.
Waiting for the agent…
The same flow, parameterized, called like an endpoint.
Waiting for a request…
GET /county/lookup?parcel=A deployment appears; the suite crawls it before anyone clicks Promote.
Waiting for a deployment…
Built for a real customer: Parcel Perfect harvests septic permits from county portals like this one. The portal here is a mock; the flow is the product.
Waiting for the agent…
A recording is the start of a conversation, not a finished artifact. You teach it the way you would teach a person: show it once, answer its questions, and it remembers.
A hosted browser opens it. Drive it yourself, or give the agent a goal and let it drive by reading the screen.
Every click and keystroke keeps a durable locator with a live uniqueness count, its alternates and a screenshot. Iframes and shadow DOM included; generated ids rejected.
Parameterize what you typed and let the agent propose a suite grounded in what it saw, inside a budget you set, not by rewriting selectors.
qareef deploy fans the flows out on the hosted runner and rolls the results up. PASS, FAIL or UNMEASURED, never a forced false fail.
The same flow is a test, a per-row data-entry job, a scheduled scraper or an API. Nothing is re-recorded to switch.
The CLI is the primary interface and never launches a browser on your machine. See the platform →
QA is the entry point, not the ceiling. If a person can do it in a browser, a flow can do it on request.
Deploy the tree, fan the flows out on the hosted runner, roll the results up. A failure files a bug with the evidence attached.
Parameterize what you typed and the flow becomes a bulk data-entry job over your spreadsheet.
Point the flow at a target list or an interval and let it accumulate a dataset for weeks.
flow_version tells a data change from a code changeThe flow declares its inputs and outputs, then answers on request. A site with no API gets one.
{account} become request parametersMost of this lands on systems that never had an API: county portals, framed ERPs, vendor back-offices. There is no integration to buy, but there is a screen, and QA Reef reads screens. Legacy system automation →
CAPTCHA handling for the app you own, gated on your authorization. Never on sites you don't control.
Anywhere the DOM churns but a human eye still knows exactly what to click.
Drawing zones on a canvas, verified by what's on screen
Whiteboards, diagram editors and floor-plan tools render into one <canvas>, leaving nothing for a selector to grab. It finds the tool, the handle and the shape by what is on screen, draws, and checks the result visually.
Panning a map, hitting the pin it can see, checking the card that opens
Slippy maps and GIS viewers redraw tiles on every pan and hide pins inside one canvas. It works from the rendered map: pans, zooms, clicks the pin it can see, and checks the popup appeared.
Typing into a hosted card field, then approving the 3-D Secure challenge
Hosted card fields live in a third-party iframe and 3-D Secure opens another, often cross-domain. It types into the frame it can see and follows the challenge, using your provider's test cards.
Signing in, then reading the one-time code off the test inbox
SSO, magic links and one-time codes break brittle scripts. It drives the sign-in like a person and reads the code from the test inbox or a TOTP secret you supply. CAPTCHAs are handled only on the app you own, gated on your authorization, never on sites you don't control.
Attaching a fixture file and waiting for the preview to show up
Native pickers, drag-to-upload zones and preview thumbnails are invisible to DOM-only tools. It attaches the fixture, watches the upload finish on screen, and checks what should appear afterwards.
The long tail: every surface where a person can still see what to click
The same screen-first approach covers the long tail. If a person can do it in a browser, it can be recorded as a flow and turned into Playwright.
Product facts, not customer metrics. We don't have those yet and won't invent them.
“The first mapping session found a checkout path nobody on the team had a test for.”
“UNMEASURED saved us from chasing a ‘failure’ that was just the staging box being asleep.”
“We pointed it at a county portal with no API and had a scheduled pull running the same afternoon.”
No. Drive your app and it records the clicks, or describe the goal and the operator reads the screen. Either way you get real Playwright code, selectors included, so you are never stuck depending on OCR at test time. Region steps cover what a selector can't say: drag a rectangle on the page and capture its text as a value, assert it shows something, or branch on it.
Anything a check could not actually observe (a page that never loaded, a flaky network hop) gets forced into FAIL by most runners. Runs here carry a third state instead. More in the blog post.
Record the flow once and parameterize the inputs. It runs on request or on a schedule and returns structured output with the evidence. No API on the target site required. Details on the website → API page.
Only on an app you own or are authorized to test: vendor test keys, a bypass token, session reuse, or a solver you configure, gated on your attestation that you control the target. On a site you don't control it never solves; the run stops, records the screen as evidence, and hands it to a person. More on the legacy system automation page.
The core (flow runtime, engine adapter, OCR-driven operator, the cost-logging LLM adapter and evidence storage) is MIT-licensed under packages/core. The hosted app is not part of that core.
Closed "coverage as a service" platforms pair a managed runner with human QA engineers. This one looks similar at the surface, but the automation core is open source, the operator reads the screen instead of needing stable selectors, and every model decision is cost-logged. There is no managed human-verification service. Sourced comparison on the compare page.
Leave an email and we'll reach out when there's a seat, or skip the form and talk to the people building it.