Turn real user flows into reliable, repeatable tests. Record directly in your app, replay them in a real browser, and get clear evidence when a run fails. No scripts required.
Our team struggled with limited testing resources for a long time. Manual regression ate our days, and recorded tests kept breaking after UI changes. So we built our own UI automation tool in-house — and it turned out so stable that we decided to release it as a product.
Unlike the typical recording tools out there, we:
1. Multi-candidate locators — every element is stored with several ways to be found, replayed as a fallback chain. UI changes break a candidate, not your test. 2. Trusted input via CDP — clicks and typing land as real browser input, so replays behave like a real user. 3. Failure evidence — every failure ships with the screenshot of the exact failing step, so you fix bugs in minutes, not hours.
If you're also short on testing resources — come give CueCast a try. We'd love to hear your feedback!
Report
Maker
Hey Product Hunt 👋 I’m one of the developers behind CueCast. I wanted to share a little about how we think about it alongside Playwright and Selenium, and where I’d like to take it.
Playwright is a great choice for teams that want tests in code, with a modern test runner and debugging tools.Selenium offers a mature WebDriver ecosystem with broad language and browser support. Both give developers a lot of control, and recording is already available through Playwright’s codegen and Selenium IDE.
With CueCast, we’re focusing on making the whole testing workflow accessible to the people who understand the product: developers, QA, and the teammates who know exactly how a business process should work.You record a flow directly in your web app, manage its steps and assertions, replay it, and inspect the results and screenshots in one place. Everyday test creation and maintenance don’t require setting up a separate scripting project.
The core of CueCast is turning real interactions into reusable, inspectable test cases. Recording is the starting point. Keeping those tests useful as the product changes is the harder engineering problem.That also shapes our approach to AI. We use it to help clarify step intent and investigate failures, while keeping recorded steps as the foundation of replay. For me, trust means being able to understand what a test did and why it failed.
Looking ahead, I’m interested in reducing maintenance work: helping teams understand which UI changes matter, suggesting updates they can review, and making failure reports more actionable. I’d also like to explore how CueCast can fit alongside existing developer testing workflows.The experience I want is simple: someone who knows the product can contribute a useful regression test, and a developer can still investigate it when something breaks.
I’d love to hear from people using Playwright or Selenium: where does most of your testing effort go today—writing tests, maintaining them, or figuring out why they failed?
Hi PH! I'm the founder of CueCast.
Our team struggled with limited testing resources for a long time. Manual
regression ate our days, and recorded tests kept breaking after UI
changes. So we built our own UI automation tool in-house — and it turned
out so stable that we decided to release it as a product.
Unlike the typical recording tools out there, we:
1. Multi-candidate locators — every element is stored with several ways
to be found, replayed as a fallback chain. UI changes break a
candidate, not your test.
2. Trusted input via CDP — clicks and typing land as real browser input,
so replays behave like a real user.
3. Failure evidence — every failure ships with the screenshot of the
exact failing step, so you fix bugs in minutes, not hours.
If you're also short on testing resources — come
give CueCast a try. We'd love to hear your feedback!
Hey Product Hunt 👋 I’m one of the developers behind CueCast. I wanted to share a little about how we think about it alongside Playwright and Selenium, and where I’d like to take it.
Playwright is a great choice for teams that want tests in code, with a modern test runner and debugging tools.Selenium offers a mature WebDriver ecosystem with broad language and browser support. Both give developers a lot of control, and recording is already available through Playwright’s codegen and Selenium IDE.
With CueCast, we’re focusing on making the whole testing workflow accessible to the people who understand the product: developers, QA, and the teammates who know exactly how a business process should work.You record a flow directly in your web app, manage its steps and assertions, replay it, and inspect the results and screenshots in one place. Everyday test creation and maintenance don’t require setting up a separate scripting project.
The core of CueCast is turning real interactions into reusable, inspectable test cases. Recording is the starting point. Keeping those tests useful as the product changes is the harder engineering problem.That also shapes our approach to AI. We use it to help clarify step intent and investigate failures, while keeping recorded steps as the foundation of replay. For me, trust means being able to understand what a test did and why it failed.
Looking ahead, I’m interested in reducing maintenance work: helping teams understand which UI changes matter, suggesting updates they can review, and making failure reports more actionable. I’d also like to explore how CueCast can fit alongside existing developer testing workflows.The experience I want is simple: someone who knows the product can contribute a useful regression test, and a developer can still investigate it when something breaks.
I’d love to hear from people using Playwright or Selenium: where does most of your testing effort go today—writing tests, maintaining them, or figuring out why they failed?