🪸 works where selectors can't reach

Automate legacy systems that were never built with an API.

Most browser automation assumes a cooperative DOM (stable ids, a selector you can write once). A lot of the software worth automating (old frame-based ERPs, 2004-era county portals, canvas maps, bolted-on PDF viewers) has none of that, so QA Reef's operator reads the screen like a person and drives the mouse to match.

How

Look, decide, act: no DOM required.

Reads the screen

Tiled OCR (Apple Vision, or a vision-model adapter) turns a screenshot into words with pixel positions, not a DOM query.

Drives like a person

The mouse moves on a curved, jittered path and clicks, not a synthetic DOM event on a handle that may not correspond to anything visible.

Evidence per step

Every action logs a screenshot, the OCR'd text, and the exact model that decided the click (decided_by), auditable after the fact.

Flows can anchor steps to the screen itself: ocr-click and ocr-type target visible text rather than a DOM selector, so the agent can design a flow for a page that has no usable DOM at all.

Three real shapes of "no API" system

A county records portal

Government portals often run on decades-old software (Laserfiche, EnerGov, Accela, Tyler) with no API and inconsistent markup. QA Reef's operator reads the form, fills it, reads results by OCR, and clicks through: the same steps a person takes.

An old ERP with frames

Frame-based enterprise systems still run that way internally, and a selector recorded against one frame's DOM breaks when IT changes the frameset. Reading the screen sidesteps that: the operator only needs to know what a control looks like, not which frame it's in.

A PDF-viewer document fetch

An in-browser PDF viewer (plugin, canvas renderer, unreachable <iframe>) often has no selector for "next page" or "download", just a toolbar rendered as pixels QA Reef reads and clicks like anything else.

What we won't do

  • No CAPTCHA solving on systems you don't control: on an app you own or are authorized to test, QA Reef handles the challenge with vendor test keys, a bypass token, session reuse, or a solver you configure, all gated on your attestation; anywhere else it stops and records what it saw.
  • Respect terms of service and robots rules: QA Reef is for systems you're authorized to operate.
  • Record-and-stop on walls: an auth screen or permission gate reports UNMEASURED with evidence, not a guess.

Background on the UNMEASURED verdict: why a QA verdict needs a third state.

FAQ

Questions about automating legacy systems

What counts as a "legacy system" here?

Any browser app with no usable API and no stable DOM (frame-based ERPs, Laserfiche/EnerGov/Accela/Tyler-style county portals, canvas maps, embedded PDF viewers, or JS-shell apps selectors can't reach).

How is this different from traditional RPA?

Traditional RPA relies on UI element trees or fixed pixel coordinates, which break when a layout shifts. QA Reef's operator reads the screen with OCR each time it acts, locating controls by current visible text and position.

Will QA Reef solve CAPTCHAs to get in?

Not on systems you don't control. On an app you own or are authorized to test, it handles the challenge with vendor test keys, a bypass token, session reuse, or a solver you configure, gated on your attestation. Anywhere else it records what it saw and stops.

Does QA Reef respect robots.txt and terms of service?

It records and stops at walls rather than pushing through, but respecting a target's terms and robots rules is the operator's responsibility, same as any browser-automation tool.

The platform

The same recorded flow runs four ways

QA is the entry point, not the ceiling. Nothing is re-recorded to switch mode.

Test

Deploy it, fan it out, file the bug. Runs →

Data entry

Once per spreadsheet row, with evidence per row. Bulk data entry →

Scrape

On a schedule, durable and auditable. Long-running scraping →

API

A site with no API gets one. Website → API →

Read the platform overview →

Read the technique in detail

OCR words to coordinates, curved mouse paths, evidence per step: how we scripted a real, decades-old portal.

Read: Making an API out of a 2004 web portal →