Every QA engineer I’ve spoken to in the last three months has brought up the same thing. Selenium. The scripts are breaking. The UI changed and now nothing works. The team is underwater. They can’t keep up.
I hear it from inbound leads. I hear it on Reddit. I hear it in coffee chats with people who’ve been building software longer than I have.
The pain is real. I’m not going to pretend it isn’t.
We’re building Marketrix, and yes, part of what we do helps with exactly this problem. We’ve been working with teams that have hundreds of test cases they can’t get through manually. One team we work with has 600 test cases. They can only cover about 50. The rest? Their end users are the ones finding the bugs. In production. On the fly.
So when someone tells me Selenium is broken, I believe them.
But here’s the thing I keep coming back to.
If we just solve Selenium, we become another name in a very long list. Go Google “Selenium alternative” right now. You’ll find dozens of companies already there. AI-powered this, low-code that. It’s crowded because the pain is obvious, and when pain is obvious, everyone shows up with a band-aid.
I don’t want to be a band-aid company.
What Selenium pain is actually telling us
The reason Selenium scripts keep breaking is that software is moving faster than ever. AI coding tools are cranking out features at a pace that no manual QA team can match. Developers are shipping daily. UIs are changing constantly. The old model of writing brittle test scripts and hoping they hold up was already struggling. Now it’s collapsing.
But the deeper question isn’t “how do we fix the scripts faster?” It’s “why are we still testing software like it’s 2015?”
Traditional QA tests whether a button works. Whether a form submits. Whether the page loads. That’s feature testing. Important? Sure. But it only answers half the question.
The other half, the one almost nobody is answering, is: should this feature even be here in the first place? And if it should, does it actually make sense to the person using it?
Two problems, one blind spot
Here’s what I’ve been thinking about a lot lately. There are actually two broken things in how we build software right now, and the industry treats them as completely separate.
The first is QA automation. Tests are brittle, teams are underwater, scripts break every time someone moves a button. That’s the Selenium pain everyone talks about.
The second is feature validation. Teams are pushing out features faster than ever, thanks to AI coding tools. But nobody is checking whether those features actually land with real users before they ship. The result? Companies are pushing 100 features a week and killing 90% of them because no one uses them. That’s not a QA failure. That’s a product failure. And it’s happening because there’s no system for validating features from the perspective of who’s actually going to use them.
Right now these two problems live in different departments. QA handles the first. Product managers and UX researchers handle the second, usually through surveys, user interviews, or Mechanical Turk style testing. Slow, expensive, and always running behind the development cycle.
What if the same approach could solve both?
Testing features vs. validating experiences
At Marketrix, we’re building persona-based simulation. Instead of writing scripts that check if buttons work, we simulate how different types of real users actually navigate your product. The casual browser. The power user. The procurement lead who’s about to sign a six-figure contract. Each one interacts with your product differently, and each one hits different friction points.
On the QA side, this means tests that don’t break when the UI changes. Because our personas navigate the way a real user would. If the button moved, they find it, the same way you or I would. No brittle selectors. No scripts to rewrite.
On the feature validation side, this is where it gets interesting. Before you ship that new onboarding flow, you can run it through a set of personas that represent your actual user base. Not “does the form submit?” but “does a first-time restaurant owner who’s never used software like this understand what to do next?” That’s a fundamentally different question. And it’s one that no amount of Selenium scripts will ever answer.
The same persona engine that catches bugs also tells you whether the feature should exist. That’s the convergence we’re building toward.
The knowledge graph behind both
Every time we run our persona engine against someone’s product, we’re building something much more valuable than a test report. We’re building a knowledge graph of how that product actually works from a user’s perspective. Every screen, every action, every decision point. And that graph gets smarter over time as the product evolves. It doesn’t break when a button moves. It adapts.
That knowledge graph powers both sides. For QA, it’s the context that makes testing resilient instead of brittle. For feature validation, it’s the accumulated understanding of how different personas experience the product, what confuses them, what delights them, where they drop off.
That’s the moat. Not a prettier Selenium wrapper. A living, evolving understanding of your product through the eyes of the people who use it.
Why this matters now
I had a conversation recently that crystallized something for me. The real value isn’t in telling you “test case 47 failed.” It’s in telling you “your three most important user personas are confused by your onboarding flow, and here’s exactly where you’re losing them.”
One is a QA report. The other is a revenue insight. Both come from the same engine.
Right now, companies are shipping faster than ever. AI coding tools have made it trivially easy to build features. But building fast without validating from the user’s perspective is just creating a bigger pile of things to fix later, or worse, features that quietly die because nobody needed them.
The QA engineer drowning in broken Selenium scripts and the product manager watching feature adoption flatline are dealing with two sides of the same coin. Neither of them has a tool that understands the product from the perspective of a real user. That’s the gap.
And the further out you look, this gets even more interesting. When AI agents start being the primary users of software, not humans clicking buttons but agents navigating APIs and tools, you’re going to need to simulate and validate those experiences too. The concept holds whether the “user” is a person or an agent. You need to understand who or what is using your product, and whether the experience works for them.
The honest version
We’re not a Selenium killer. We’re not trying to be. We’re using the Selenium pain as a starting point to build something bigger: a system that handles both QA automation and feature validation through the lens of real user personas.
The testing side gets you confidence that things work. The validation side gets you confidence that you’re building the right things. Together, they change how teams think about quality, from “does it pass?” to “does it matter?”
Every inbound lead, every conversation with someone who’s drowning in broken test scripts or watching features die on arrival tells me the same thing. The pain is real on both sides. And the current solutions only address one.
We’re building the thing that connects them.
I’m Irosha, co-founder and CEO of Marketrix. We’re building an autonomous QA platform powered by persona-driven AI simulation. If you’re dealing with any of this, I’d love to hear from you.