Checksum is an AI-native continuous testing platform for engineering teams shipping faster than manual QA can keep up. It generates, runs, and auto-heals end-to-end and API tests on every pull request, all as standard Playwright code in your own repo. When a test fails, Checksum tells you whether it found a real bug or a stale test, then fixes the false failures so your suite keeps pace with your coding agents.
👋 Hey Product Hunt, I'm Gal, founder and CEO of Checksum.
A few years ago at my last startup, I watched our team lose entire sprints to test maintenance. Every time the product changed, someone had to go update selectors, re-triage failures, and figure out which broken tests were real bugs and which were just noise. I'd spent years before that building ML models to detect suspicious activity from satellite data—pattern recognition at scale—and it nagged me that software testing was the same kind of problem.
AI coding tools solved generation and teams can now ship far more code than ever. But they didn't solve verification; every PR still needs to be tested and trusted before it ships. Counterpart, an agentic insurance platform, runs a 10x QA team on Checksum at less than half the cost of one offshore developer, and hasn't had a production outage since. Their engineering manager Ron Alexssen put it this way: "For less than half the salary cost of an offshore developer, I have the impact of a full QA team."
That’s why we built Checksum. Our agentic loop runs in two parts:
🔁 Generate and maintain. On every pull request, an agent spins up in a sandbox, detects what changed, and generates or updates your End-to-end and API tests automatically. No written selectors by hand.
🔁 Run, report, fix. Trigger your suite from a PR, the API, or MCP. When something fails, a second agent triages it: real bug, or broken test by a product change? Real bugs route to Jira, Linear, or Slack. Broken tests get fixed autonomously. Söderberg & Partners went from zero to full coverage in weeks and now reclaims 90 hours of manual testing a month. Postilize cut bugs by 70% and sped up engineering cycles by 30%, with zero flaky tests.
Everything ships as standard Playwright code committed to your own repo. No proprietary format, no lock-in. And the agent doesn't just chase easy passing tests, it goes after the hard cases too: auth boundaries, edge flows, the stuff that's tedious to test manually and easy for AI to skip if you let it.
🎁 Product Hunt community gets a free 30-day trial with code PHLAUNCH
We're here all day, ask us anything. 🙏
Report
💡 Bright idea
The stale test detection is the part that caught my attention. AI generated code is only useful if the tests dont become another maintenance job.
@ashir_murtaza1 Yes! Generating tests quickly is the easy part now. The hard part is what happens after that first test when your app's changed multiple times and half your suite is red for reasons that have nothing to do with a real bug.
With Checksum every failure gets triaged before it ever hits you team: real bug vs. stale test. Real bugs route straight to your team. Stale tests get healed. 70% of failures resolve that way without anyone touching them.
If you've been burned by a suite that turned into a maintenance job before, genuinely curious what broke it, selectors, flaky timing, something else? Helps us make sure we're solving the actual pain, not just the version of it we assumed.
@ashir_murtaza1 90% of the cost of software is always maintenance - same thing is true of your giant code-gen'd test suite as the rest of your app. Should you care when one flips red? We think emphatically no. We have a classifier look into if the original intent is still possible, if it can still be achieved we think no human needs to care about that or even be notified.@michelle_dailey totally correct, you'll just see a merged and working test update in your git history, if not and it's a real break we'll reach out to you on slack with screenshots, traces, logs + links
Would you suggest using this for more elaborate claude code projects (full stack, hosted)? I'm the owner of a few of our internal tools and I'm trying to figure out where I can/should fit something like Checksum into the stack. I'm frequently worried about random bugs and keeping the tools running as smoothly as possible.
@michaelsand To add a bit more since this sounds like a specific situation: internal tools are a great fit for this, precisely because they're the tools least likely to have dedicated QA watching them. Checksum tests against your actual hosted environment, so it's not limited to a specific stack, and once tests exist they don't just run once, failures get triaged (real bug vs. something that broke because the UI changed) and broken tests get healed rather than left red and forgotten, which is usually where internal-tool test suites quietly die.
Would depend a bit on where your repo and CI live and how your environments are reached, happy to get into specifics if useful. Is the "random bugs" worry mostly about regressions from AI-generated changes specifically, or more general "nobody's watching these tools" risk?
@michaelsand yea full stack (we love playwright + api) and hosted is what we test most often, vpns or proxies very normal for us to need to get set up with clients for internal tool testing. Yea everyone is in nail-biter mode right now with releases. Software Engineering best practices are yet to crystalize for the new normal. We think we've a shot at being one of those must buys
@sansa_grey That's why we went with it. With Playwright in your repo, you can read exactly what a test does, edit it if something's off, and if you ever walk away from Checksum, every test walks with you. No migration, no rewrite.
It also means the tests fit into whatever review process you already trust, a generated test shows up as a normal PR, gets reviewed like any other code change, not approved through some separate tool.
Report
@benln can it test changes across multiple services in the same PR?
@athar_jatoi Agreed, and the false failures are often worse than the real ones because they train people to ignore the suite. Telling a real bug from a stale test is the core of what the healing workflow does.
@hamza_afzal_butt It's such a great question! You start by reviewing a few changes, and as you see the model making the right decisions, you start to build confidence.
@hamza_afzal_butt Adding a bit more to this, every healed test change lands as an actual diff you can review, not a silent overwrite. So you're never blindly trusting the model, you're reviewing it the same way you'd review any other code change. In practice, teams tend to check closely at first, and once you've seen the same failure mode (a selector rename, say) get correctly resolved a handful of times, you naturally stop needing to check every instance of that type.
Watch Something
👋 Hey Product Hunt, I'm Gal, founder and CEO of Checksum.
A few years ago at my last startup, I watched our team lose entire sprints to test maintenance. Every time the product changed, someone had to go update selectors, re-triage failures, and figure out which broken tests were real bugs and which were just noise. I'd spent years before that building ML models to detect suspicious activity from satellite data—pattern recognition at scale—and it nagged me that software testing was the same kind of problem.
AI coding tools solved generation and teams can now ship far more code than ever. But they didn't solve verification; every PR still needs to be tested and trusted before it ships. Counterpart, an agentic insurance platform, runs a 10x QA team on Checksum at less than half the cost of one offshore developer, and hasn't had a production outage since. Their engineering manager Ron Alexssen put it this way: "For less than half the salary cost of an offshore developer, I have the impact of a full QA team."
That’s why we built Checksum. Our agentic loop runs in two parts:
🔁 Generate and maintain. On every pull request, an agent spins up in a sandbox, detects what changed, and generates or updates your End-to-end and API tests automatically. No written selectors by hand.
🔁 Run, report, fix. Trigger your suite from a PR, the API, or MCP. When something fails, a second agent triages it: real bug, or broken test by a product change? Real bugs route to Jira, Linear, or Slack. Broken tests get fixed autonomously. Söderberg & Partners went from zero to full coverage in weeks and now reclaims 90 hours of manual testing a month. Postilize cut bugs by 70% and sped up engineering cycles by 30%, with zero flaky tests.
Everything ships as standard Playwright code committed to your own repo. No proprietary format, no lock-in. And the agent doesn't just chase easy passing tests, it goes after the hard cases too: auth boundaries, edge flows, the stuff that's tedious to test manually and easy for AI to skip if you let it.
🎁 Product Hunt community gets a free 30-day trial with code PHLAUNCH
We're here all day, ask us anything. 🙏
The stale test detection is the part that caught my attention. AI generated code is only useful if the tests dont become another maintenance job.
Checksum AI
@ashir_murtaza1 Yes! Generating tests quickly is the easy part now. The hard part is what happens after that first test when your app's changed multiple times and half your suite is red for reasons that have nothing to do with a real bug.
With Checksum every failure gets triaged before it ever hits you team: real bug vs. stale test. Real bugs route straight to your team. Stale tests get healed. 70% of failures resolve that way without anyone touching them.
If you've been burned by a suite that turned into a maintenance job before, genuinely curious what broke it, selectors, flaky timing, something else? Helps us make sure we're solving the actual pain, not just the version of it we assumed.
Checksum AI
@ashir_murtaza1 90% of the cost of software is always maintenance - same thing is true of your giant code-gen'd test suite as the rest of your app. Should you care when one flips red? We think emphatically no. We have a classifier look into if the original intent is still possible, if it can still be achieved we think no human needs to care about that or even be notified.@michelle_dailey totally correct, you'll just see a merged and working test update in your git history, if not and it's a real break we'll reach out to you on slack with screenshots, traces, logs + links
Littlebird
Would you suggest using this for more elaborate claude code projects (full stack, hosted)? I'm the owner of a few of our internal tools and I'm trying to figure out where I can/should fit something like Checksum into the stack. I'm frequently worried about random bugs and keeping the tools running as smoothly as possible.
Watch Something
@michaelsand Yep, our bread and butter is complex applications
Checksum AI
@michaelsand To add a bit more since this sounds like a specific situation: internal tools are a great fit for this, precisely because they're the tools least likely to have dedicated QA watching them. Checksum tests against your actual hosted environment, so it's not limited to a specific stack, and once tests exist they don't just run once, failures get triaged (real bug vs. something that broke because the UI changed) and broken tests get healed rather than left red and forgotten, which is usually where internal-tool test suites quietly die.
Would depend a bit on where your repo and CI live and how your environments are reached, happy to get into specifics if useful. Is the "random bugs" worry mostly about regressions from AI-generated changes specifically, or more general "nobody's watching these tools" risk?
Checksum AI
@michaelsand yea full stack (we love playwright + api) and hosted is what we test most often, vpns or proxies very normal for us to need to get set up with clients for internal tool testing. Yea everyone is in nail-biter mode right now with releases. Software Engineering best practices are yet to crystalize for the new normal. We think we've a shot at being one of those must buys
Buffup.AI
Playwright code staying in the repo is a nice choice. i do much rather have tests i can inspect and edit than another black-box- QA layer.
Checksum AI
@sansa_grey That's why we went with it. With Playwright in your repo, you can read exactly what a test does, edit it if something's off, and if you ever walk away from Checksum, every test walks with you. No migration, no rewrite.
It also means the tests fit into whatever review process you already trust, a generated test shows up as a normal PR, gets reviewed like any other code change, not approved through some separate tool.
@benln can it test changes across multiple services in the same PR?
Watch Something
@benln @rosalie_autumn yes it can! Checksum specializes in complex cases across surfaces and users
The take test detection caught my attention. False failures can waste so much time that fixing those automatically could be really useful.
Checksum AI
@athar_jatoi Agreed, and the false failures are often worse than the real ones because they train people to ignore the suite. Telling a real bug from a stale test is the core of what the healing workflow does.
Checksum AI
@athar_jatoi @michelle_dailey Yep false alarms suck, going to refer you to my answer on another thread: https://www.producthunt.com/products/checksum-ai?comment=5804429
How do teams build confidence in auto healed tests without manually reviewing every change?
Watch Something
@hamza_afzal_butt It's such a great question! You start by reviewing a few changes, and as you see the model making the right decisions, you start to build confidence.
Checksum AI
@hamza_afzal_butt Adding a bit more to this, every healed test change lands as an actual diff you can review, not a silent overwrite. So you're never blindly trusting the model, you're reviewing it the same way you'd review any other code change. In practice, teams tend to check closely at first, and once you've seen the same failure mode (a selector rename, say) get correctly resolved a handful of times, you naturally stop needing to check every instance of that type.
Curious what's behind the question for you?