Most startups ship fast and have no QA team, so tests get written late, break often, and quietly get ignored. Blop fixes that. You describe what your app should do in plain English. Blop builds a deep map of your product, tests it like a real user on every deploy, and when something changes and a test breaks, it repairs the test and opens a PR for you to review. The tests stay as real code in your repo. You own them. Nothing locked inside our tool.
Hey everyone, Alejandro here, one of the cofounders.
Me and Hanan build a lot with vibecoding tools, and we kept hitting the same wall. You move so fast that you stop reading every diff, and slowly a gap opens between you and your own codebase. Clean code you don't fully understand. It shows up worst when something breaks and you can't tell if the test is wrong or the app is wrong.
We wanted something that understood our projects as deeply as we used to, back when we read every line. So we built Blop. It holds the full picture of what your app is supposed to do, watches it on every deploy, and tells you when reality drifts from intent. It repairs its own tests and hands you a PR, and everything lives in your repo as code you own.
We're opening it up to startups and SaaS teams now. We mostly want honest feedback, especially the critical kind. What's confusing, what's missing, what would make you actually use it.
Happy to answer anything here.
The locator-only healing is a clever constraint - it answers the regression-masking concern pretty cleanly. The harder problem I'd push on is spec drift: "user can sign up and check out" sounds stable but the flow itself evolves constantly in early-stage products. When checkout adds a promo code step, or signup adds phone verification, Blop's deep map of expected behavior is now wrong - but locators might still pass. Does Blop have a way to surface when the original description no longer matches what the product actually does, or does that gap just quietly accumulate until a real regression gets missed?
the vibecoding gap you described is painfully accurate, you move so fast you slowly stop recognizing your own codebase. the thing that makes me trust this is that the tests land in my repo as real code i own, so when it opens a PR i can read exactly what changed. nice work Alejandro.
Do you plan support for mobile/multi platform/cli products testing as well?
Congrats! I wonder how does Blop ensure the generated test code matches your team's existing patterns and naming conventions?
The timing for this feels right. Vibe coding makes it easy to move fast, but after a few rounds you start needing something that remembers what the app was supposed to do.
The self-healing part is what I keep thinking about. Writing tests is one problem, but the real grind is maintaining them after every refactor, and that's usually what causes teams to just give up on the test suite entirely. The "deep map" approach of tracking intended behavior rather than implementation details sounds like it could survive code changes better than traditional tests. The concern I'd have is the edge case where Blop quietly repairs a test that was actually catching a real bug. How do you distinguish between a test that broke because the product changed versus a test that broke because something is genuinely wrong?
If it auto-fixes its own tests when the product changes, what stops it from "fixing" a test into passing when the underlying behavior actually broke? That's the core tension with self-healing test tools generally, how do you tell the difference between an intentional UI change and a regression if the system's first instinct is to adapt rather than flag?
Ok two feedback’s
1. Your idea is solid and it’s true I have myself shipped vibecoded ios apps that have paying customers the issue is testing and figuring out what is broken.
2. Demo video is really bad after opening for 2-3 sec I stopped cause it didn’t grabbed the attention it is simple I mean the zoom in and zoom out thing is cool but you should do something random in 1-4 sec of the video.
How does Blop distinguish between an intentional product change and a bug ? I'd be curious to understand what signals it uses before deciding to repair a test automatically.
About Blop on Product Hunt
“Describe your app and Blop tests it and repairs broken tests”
Blop launched on Product Hunt on June 25th, 2026 and earned 82 upvotes and 16 comments, placing #23 on the daily leaderboard. Most startups ship fast and have no QA team, so tests get written late, break often, and quietly get ignored. Blop fixes that. You describe what your app should do in plain English. Blop builds a deep map of your product, tests it like a real user on every deploy, and when something changes and a test breaks, it repairs the test and opens a PR for you to review. The tests stay as real code in your repo. You own them. Nothing locked inside our tool.
Blop was featured in User Experience (366.6k followers), Software Engineering (42.7k followers) and GitHub (41.3k followers) on Product Hunt. Together, these topics include over 63.1k products, making this a competitive space to launch in.
Who hunted Blop?
Blop was hunted by Alejandro Laurlund Gato. A “hunter” on Product Hunt is the community member who submits a product to the platform — uploading the images, the link, and tagging the makers behind it. Hunters typically write the first comment explaining why a product is worth attention, and their followers are notified the moment they post. Around 79% of featured launches on Product Hunt are self-hunted by their makers, but a well-known hunter still acts as a signal of quality to the rest of the community. See the full all-time top hunters leaderboard to discover who is shaping the Product Hunt ecosystem.
Want to see how Blop stacked up against nearby launches in real time? Check out the live launch dashboard for upvote speed charts, proximity comparisons, and more analytics.
Alejandro Laurlund Gato