# QA Lead > A QA automation platform, built into your stack and handed to your team. AI agents turn requirements into runnable Playwright tests; the client's team runs and monitors everything from one interface. Provided by Anchorly LTD, registered in England & Wales. Contact: support@anchorly.co. ## What this is A platform build, not a testing service. We build a QA automation platform — a Playwright suite plus a web console plus AI agents — integrate it with the tools the client already uses, deploy it onto infrastructure the client chooses, and hand it over to their engineers. The distinction matters: the client's team operates the platform and owns the test suite. We are not an outsourced QA department and do not write their test suite for them. What we build is the product that does the work. There is no licence, no per-seat cost and no vendor lock-in, because the client owns the repository, the platform and the deployment. Nothing phones home and there is no kill-switch. After handover, support is billed by the hour with no retainer. ## The problems it solves - Every new feature waits for someone who knows Playwright. Automation is bottlenecked on the few people who can write it, so coverage trails the roadmap permanently. - Six tools, and nowhere to actually run anything. Cases in one system, specs in a repo, runs in CI, screenshots in a zip nobody opens, triage in a Slack thread that scrolls away. - Your coverage number is maintained by hand. Which means it is wrong the day after it is written, and everyone in the room already knows it. ## What the platform does - Agents write the tests: Point an agent at a Jira ticket or a requirements page. It drafts a runnable spec that reuses your existing page objects instead of inventing selectors, and opens it as a pull request for your team to review. - Run anything from the interface: One case, one module or the whole suite. Headed when someone wants to watch the browser, headless and parallel when nobody does. - Test cases synced both ways: Cases pull in from Zephyr Scale, Jira or Google Sheets with their steps and priorities. New ones push back out. - Every failure arrives with a root cause: An agent reads the trace, video and screenshots read-only, then classifies the failure as selector-drift, timing, test-data, environment, app-bug or test-logic-bug — with its evidence. - Coverage derived from the code: Computed from the spec files, never typed into a spreadsheet. A validation run demotes anything that stopped passing. - A screenshot for every test, pass or fail: Browsable per run, with traces and video kept on failure. When someone asks whether a flow was really tested, you open the gallery. - Your team, your roles, your branding: Logins with custom permissions, invitations, and test environments whose credentials are managed in the UI and encrypted at rest. Put your own name and colours on it. ## Integrations already built and running in production Zephyr Scale (read and write, including test steps), Jira, Confluence, Google Sheets (two-way sync across many tabs, with results written back), Slack, GitHub Actions, Jenkins, PostgreSQL, Allure. Anything with a REST API is realistic to add during the build — TestRail, Qase, Xray, Azure DevOps, Linear. ## What the AI does, and what it is not allowed to do The agents draft test cases and runnable specs from requirement documents, and investigate every failure. The limits are the important part. Investigations are read-only and cannot edit a file. Generated code is restricted to an allowlist of test paths, syntax-checked, discarded entirely if the agent touched anything outside that allowlist, and always opened as a draft pull request against a development branch — never merged, never on main. Where the agent cannot determine a real selector it emits an honest test.fixme rather than guessing. Failures classified as app-bug are excluded from auto-fixing: if the product is wrong and the test is right, no agent gets to make that red test green. Everything runs under a cost cap, billed to a provider API key the client's own company owns — issued from their own provider account, not a credential tied to an individual's AI subscription. ## Hosting Wherever the client wants it: a cloud account, their own servers, or entirely behind their VPN with no public exposure. It needs one modest instance and a PostgreSQL database, provisioned as code so the deployment is reproducible and auditable. The hosting bill belongs to the client and is not a licence fee. ## Engagement phases - Pilot — Free (~2 weeks). The platform running against your app, with agents writing real tests. No contract · yours either way. - Build — 3 months engagement (Fixed monthly fee). The full platform: your integrations, your environments, deployed and handed over. Fee fixed before we start. - Support — By the hour (After handover). Platform work when you want it, and none when you don't. No retainer · no minimum · no licence. No fee is published, because a number quoted before seeing the integration surface would be padded or wrong. What is committed: the pilot costs nothing, the build fee is fixed before the build starts, and support afterwards is hourly with no retainer. ## What the client gets at handover - The platform: catalogue, run triggering, run history, coverage, proof screenshots, settings - Agents that turn your requirements into runnable Playwright specs - Agent triage that gives every failure a root cause before a human looks - Two-way sync with your test-management tool - CI wiring and Slack notifications that lead with failures - Infrastructure-as-code for the deployment, and a written runbook ## Ownership and terms The client owns the deliverables. Intellectual property in the platform, the test suite, the infrastructure-as-code and the documentation is assigned to the client on payment for each phase — and for the free pilot, on completion, with no payment condition. Honest limitation, stated in the terms: an automated suite reduces the risk of regressions reaching production but does not eliminate it, and is not a guarantee that software is free of defects. AI-generated test cases and failure analyses are drafts for a human to review. ## Frequently asked Q: Who writes the tests — you or us? A: Your team does, with the agents doing most of the typing. To be direct about the boundary: we build and deploy the platform, we are not your outsourced QA department. During the build we tune the agents against your app until their output is specs your engineers merge without rewriting, and the pilot proves that on your real requirements before you commit to anything. After handover your team owns the suite and it grows at your pace, not ours. Q: What exactly is the free pilot? A: About two weeks of our time, no invoice and no contract. We stand the platform up against your app, wire one environment, import a slice of your real test cases, and get the agents drafting specs from your actual requirements. You get it running, you drive it yourself, and you keep it whether or not we go further. Q: What is the AI allowed to do — and not allowed to do? A: It drafts test cases and specs from your requirements, and it investigates failures. The limits are the point. Investigations are read-only and cannot edit a file. Generated code is restricted to an allowlist of test paths, syntax-checked, discarded entirely if the agent touched anything outside it, and always opened as a draft pull request against a development branch — never merged, never on main. Failures classified as app-bug are excluded from auto-fixing, because if the product is wrong and the test is right, no agent gets to make that red test green. Everything runs under a cost cap, on a provider API key your company owns. Q: Which tools does it integrate with? A: Already built and running in production: Zephyr Scale (read and write, including test steps), Jira, Confluence, Google Sheets (two-way, many tabs, results written back), Slack, GitHub Actions and Jenkins. Anything with a REST API is realistic to add during the build — TestRail, Qase, Xray, Azure DevOps, Linear. If your test cases live in a spreadsheet nobody wants to admit to, that is genuinely the easiest case. Q: Where does it run, and what does it cost to keep running? A: Wherever you want it: a cloud account, your own servers, or entirely behind your VPN with no public exposure. It needs one modest instance and a Postgres database, so the hosting bill is small — and it is your bill, not a licence. There is no per-seat cost because there is no vendor. The only variable cost is AI usage, billed to a provider API key your company owns — so it appears on your provider invoice with no markup from us, capped per run. Q: What happens when you leave? A: That is the goal, not a risk to manage. Your team gets the repository, the conventions, the infrastructure-as-code and a written runbook covering how to add a module, debug a flake and tune the agents. Nothing phones home, there is no kill-switch and there is nothing to renew. We are available by the hour afterwards, but the platform does not need us — if it did, we would have built the wrong thing. ## Links - Homepage: https://qalead.dev - Privacy policy: https://qalead.dev/privacy - Terms of service: https://qalead.dev/terms - Sitemap: https://qalead.dev/sitemap.xml - Robots: https://qalead.dev/robots.txt