My Team Was About to Pay for a Test Automation Tool. I Built One Instead.
When the conversation came up about investing in a commercial tool to bridge the gap between manual testing and automation, I quietly went away and built Skopix instead. Three weeks later it was live.
A few months ago the conversation came up at work about a tool called Qure, a JetBrains product that turns manual web testing flows into automated tests. The idea behind it is solid. You record what you do in the browser and the tool handles the automation code. The pitch is that it lowers the barrier between manual testers and the automation pipeline.
I understood the appeal immediately. The problem it is solving is one I live with every day.
But I also thought: I could build this.
The problem it solves
The overhead of automation in most QA teams sits in a specific place. It is not that engineers do not know how to write Playwright or Selenium tests. It is that the gap between a manual tester identifying something worth automating and that thing actually becoming an automated test is too wide and too slow.
A manual tester finds a flow that should be regression tested. They write it up. It goes into a backlog. The SDET picks it up when they have capacity. They figure out the selectors, write the test, get it reviewed, merge it. By the time that flow is actually in the suite, weeks have passed and the feature has moved on.
What I wanted was a way for non-technical testers to create something an SDET could actually use. Not just a description. A real artefact. A recorded flow with stable selectors and generated Playwright code that drops straight into the existing test setup with minimal rework.
That is what Skopix does.
How it works
The tester opens Skopix, clicks record, and a real Chrome window opens. They use the app exactly as they normally would. Click, type, navigate, scroll. Every action is captured. They add assertions by clicking a button in a floating toolbar, picking an element, and choosing what to verify. No knowledge of selectors, no code, no configuration.
When they stop recording, an LLM processes the raw steps. It rewrites fragile positional selectors into stable semantic equivalents, data-testid attributes, aria-labels, semantic HTML. It generates complete Playwright test code in both JavaScript and TypeScript. The tester ends up with a named test, a step-by-step description of what it does, and production-ready code.
The SDET gets that file, reviews it, drops it into the CI pipeline, done. The automation overhead shrinks dramatically because the first draft is already done and done properly.
Why I built it instead of buying
Partly because I genuinely believed I could. Partly because building it would teach me things that buying it would not. And partly because a tool built specifically for how my team works will always fit better than a commercial product designed for everyone.
Qure is a solid product. JetBrains build good software. But it is a desktop app with its own conventions and its own way of doing things. Skopix is self-hosted, runs as a local dashboard, works in solo mode for individuals and team mode for a shared QA setup, and integrates with Portix for remote sharing. It is built around how I actually work.
There is also something worth saying about the cost. A commercial tool at scale is not cheap. Skopix is free, open source, and runs entirely on your own machine. If you use Ollama for the AI processing, not a single byte of your test data leaves your network.
Three weeks to build it
The core recording and replay loop came together in the first week. Capturing browser actions via a Chrome extension, streaming them back to the dashboard, storing them as structured YAML, replaying them deterministically. That is the heart of the product and it works cleanly.
The second week was mostly the AI processing layer and the team mode infrastructure. Getting the LLM to consistently produce stable selectors and clean Playwright code required more prompt engineering than I expected. The model needs to understand the difference between a selector that will survive a UI change and one that will not. Getting that right reliably took iteration.
The third week was polish, edge cases, and the features that make it feel like a real product rather than a prototype. Debug recording, where you can set a breakpoint on any step and Skopix replays up to that point then hands control back to you. Setup flows, where you record your login once and every other test can reference it. Credential management so passwords are never stored in plain text in the test YAML. The HTML session reports with video and screenshots.
What it means for the team
The goal was always to reduce the automation overhead without reducing the quality of what gets automated. A non-technical tester can now create something an SDET can genuinely use. The manual testing knowledge that existed in people's heads can be captured as a reusable artefact rather than evaporating at the end of a test session.
That shift matters more than any individual feature in the tool. The bottleneck was always the translation step between knowing something should be automated and it actually being automated. Skopix removes most of that friction.
It is live at skopix.ayteelabs.com and on GitHub. Free, self-hosted, one command to get started.