Quick start: your first recorded test in one sitting
Create a free account, verify your email, name a workspace, point the recorder at a URL you are allowed to test, and click through one flow. The recording repla…
Documentation
Guides written by the people who build each module
Answer first, then the how, then the limits. Every guide is dated, and every capability named in it is checked against the shipped product before it is written down.
16Product modules
60+Security engines
66Accessibility standards
21Interface languages
How you will use it
One recording is the shared input. Record it once, reuse it across every module, and hand a reviewer the evidence each run produces.
Record one flow
Point the recorder at a URL you are allowed to test and click through one journey in a real browser. Every step, selector, network call and assertion is captured as you go, and nothing is installed on your machine.
Recording your first testReuse it across the platform
The same recording becomes a regression test, a load profile, a security scan and an accessibility audit. One set of test assets, read by every module, so a change is made in one place, not in four copies that drift apart.
How the modules share one inputHand over the evidence
Each run produces something a reviewer can check without trusting the tool: an evidence bundle on a confirmed finding, a VPAT from a real scan, percentile latency, or exported Playwright, Cypress or Selenium code.
What an evidence bundle contains
Quick start
Sign up, verify, point the recorder at a URL, record one flow, run it. One sitting, nothing installed.
Read the guideAPI testing studio
REST, GraphQL, gRPC and SOAP in one studio. Import Postman, Insomnia, Bruno or Hoppscotch collections.
Read the guideCI/CD integration
GitHub, GitLab, Jenkins, Azure DevOps and Bitbucket, quality gates, signed webhooks and DORA metrics.
Read the guideSecurity and data handling
Where data lives, what leaves your tenant, identity controls and the evidence your reviewers will ask for.
Read the guideStart here, by what you do
Pick the row that sounds like your job. Each is a short reading order, not the whole library.
You lead QA or write tests
Will it cut my maintenance, and can I keep my framework?
You own security or compliance
Can I trust a finding, and where does our data live?
You decide and you buy
What does it cost to run, and what happens if we leave?
Browse by topic
19 published guides across 12 topics, last updated 2026-09-18. 2 more are planned and listed below without a link, so nothing here leads to a page that does not exist yet.
What makes this different
Six choices behind the platform, each one you can check in a guide. We do not claim to beat any one tool at its own game. The honest side by side is on the comparison page.
One workspace, not five
Most teams run five tools that each keep a private copy of the same environments, credentials and selectors. When one changes, four copies go stale. Here there is one project, and every module reads from it.
Evidence, not just a list
A confirmed security finding carries the proving request, the response and a proof of concept you can replay. An observation the platform cannot reproduce is labeled as such, and never fails a gate.
A person approves every heal
A test that silently re-targets itself to the wrong element passes while the product is broken. So every self-healing repair is a proposal with a diff, and a human approves it before it lands.
Your code stays in your tenant
Test intelligence runs on local open-source models inside the platform. No code, test data or prompt is sent to OpenAI, Anthropic, Google or Meta, and no customer data trains any model.
Export and leave whenever
Recordings export as Playwright, Cypress or Selenium; load tests to k6, JMeter or Locust; API collections in open formats. Leaving costs you the shared repository, not your tests.
Limits are stated, not buried
Every guide names where a capability stops. If we have not measured something across customers, we say so instead of printing a number we cannot stand behind.
How these guides are written
Four rules, so an evaluator at a large company can trust a page without a call.
Dated
Every guide shows the date it was last checked. A guide without a date is a rumour.
Checked against the code
A capability is named only after it is verified in the shipped product. Limits are stated in the same guide, not in a footnote.
Answer first
The summary at the top of each guide is the answer. The sections below explain how and where it stops working.
Written for reviewers too
The security and data-handling guide is written to be pasted into a vendor questionnaire, including the parts that are still in progress.
Something missing?
Questions are answered by the engineers who build the platform, typically within one business day. Enterprise customers get direct engineering escalation.