It started with frustration. Every time I sat down to write automated tests for a web application, I'd spend more time figuring out how to find an element than actually writing the test logic. I'd inspect an element in Chrome DevTools, copy what looked like a reasonable selector, paste it into my test, run it — and it would either match five elements instead of one, or break completely the next sprint when a developer renamed a class. The existing tools helped you generate selectors but none of them told you whether the selector you just copied was actually any good. You were left guessing. A selector that worked today might be completely useless in two weeks. That uncertainty was costing real time across every project. There are really three problems wrapped into one: The first is selector quality. Most developers and testers grab the first selector DevTools suggests — which is often an absolute XPath seven levels deep, or a CSS selector built on auto-generated class names that change every build. Nobody warns you. SelectorPro's stability score exists to fix that — to give you an honest answer about whether the selector you're about to use will still work next month. The second is context switching. Writing a test used to mean: inspect in DevTools, copy selector, switch to IDE, write the find_element call, look up the syntax, switch back to browser, check it matches. SelectorPro collapses that into one panel — inspect, copy, generate ready-to-paste code, done. The third is the AI gap. Test automation has always been a skill that requires knowing XPath syntax, CSS combinators, framework-specific locator APIs. That excluded a lot of people who understood testing conceptually but found the syntax barrier too high. Natural language to selector was the feature that made me most excited to build — the idea that you could just describe what you want and get a working, stable selector back. Honestly the first version was much more modest. It was going to be a simple popup — click the icon, click an element, get a CSS selector and an XPath, done. Two selectors. No scores, no AI, no code generation. But the more I thought about the actual workflow of someone writing Selenium or Playwright tests, the more I realised a two-selector popup would solve maybe twenty percent of the friction. The real time sink wasn't generating the selector — it was everything around it. Validating it, translating it into the right framework syntax, deciding which of five generated selectors was actually trustworthy, and then six months later when a test breaks at 2am, having no idea which selector to fix or why it broke. So the scope expanded. The stability score came from asking: what would a senior automation engineer look at when reviewing a selector in a pull request? They'd look for dynamic IDs, positional indices, generated class names. So I codified that into a scoring system. The code generator came from noticing I was writing the same WebDriverWait and driver.find_element boilerplate fifty times. The AI features came last — and they changed everything, because suddenly the tool wasn't just faster, it was accessible to people who'd never written an XPath in their life. The biggest shift in thinking was moving from "a tool that generates selectors" to "a tool that makes test automation less intimidating for everyone." That reframe changed every decision after it — the UI, the onboarding, the help guide, the natural language feature, the chat assistant.

SelectorPro

Selector fragility was quietly killing test.

Selector fragility was quietly killing test.