Launching today
Drizz
Mobile tests that write, run, and fix themselves
210 followers
Mobile tests that write, run, and fix themselves
210 followers
Drizz is an AI-powered mobile test automation platform built around intent-based testing. Simply describe what you want to test in plain English, Drizz executes it on a real device using Vision AI and automatically authors a reusable test case. No scripting, no flaky selectors, no manual maintenance. It adapts to dynamic UIs, integrates with your CI/CD pipeline, and gives your team reliable end-to-end coverage without the overhead.
I'm building a couples app on iOS, and my whole testing setup right now is XCUITest on simulator + manual checking, archived to TestFlight by hand. Probably the exact cohort that'd never write Appium tests but might genuinely try this. The question I'd love your take on: with Vision AI driving execution, how do you keep tests deterministic across CI runs? Selectors fail predictably...locator doesn't exist, you fix it. A vision model can fail by misreading a screen state on one run and reading it correctly the next, which feels harder to debug. And there's a scary version of "self-healing" where the AI silently re-interprets what success means. What's the rerun / confidence story, and where do you draw that line?
Congrats on the launch!
Drizz
@ferdi_sigona - Really sharp question, and honestly the right one to ask before trusting any Vision AI system with CI.
The short answer: we've put a structured reliability layer underneath the vision execution specifically to prevent the "reads it differently on Tuesday" problem. It's not raw model inference on every step — there's a multi layer determinism mechanism that makes repeat runs behave consistently, not probabilistically. All of our customers have hit 95% + reliability on the tests in CI/CD
On self-healing — this is the part most tools get wrong, and it's something we were very deliberate about. The healer doesn't reinterpret what success means. It only engages when the UI has structurally changed around a test that was written correctly. Classic example: you wrote a test when your app had no color picker. A later build adds one. The healer identifies the missing piece, executes it and gets back on the path you defined, it doesn't decide your test meant something else. The intent you authored is treated as fixed; only the route to executing it can adapt. A single tests can have multiple healer sessions dependign on how far behind your testcases are wrt your release version
Given you're on XCUITest + TestFlight today, this would likely slot in without much friction — worth a conversation if you want to see it on a real flow.
Try Out Drizz right here, we are giving free launch day credits: https://www.drizz.dev/download-desktop-app. Reach out to us in case you face any issues.
Drizz
Hey Product Hunt! 👋
I'm Yash, co-founder of Drizz. Along with my co-founders, Partha and Asad, we've spent the last year building the mobile testing tool we always wished existed.
💡 How it started
I once spent 3 hours debugging a broken test, only to find a designer had moved a button 12px to the left. That was the moment I knew legacy systems was broken. Not "could be improved." Fundamentally broken.
XPaths that shatter when a UI changes. Test suites that need a dedicated engineer just to stay alive. We lived this at Amazon and Coinbase. Teams shipping slower than they should because testing was a tax, not a tool. So we built our way out of it.
🚀 One sentence in. A complete test out.
Drizz is a Vision AI mobile testing agent. You write what you want to test in plain English, just the goal. Drizz reasons about your app, generates the full test, and executes it on a real device.
"Search for stays in Spain for 8th–10th April for one adult"
→ Drizz reads the app visually, builds every step, runs it on a real iPhone. No selectors. No scripts. No maintenance.
What Drizz does differently:
✍️ Plain English authoring: describe the goal, Drizz builds the test
🔮 Vision AI execution: reads your app like a human, not the DOM
🩹 Self-healing tests: UI changed? Drizz adapts automatically
📱 Real device execution: iOS & Android, not simulators
🔗 CI/CD native: GitHub Actions, GitLab, Jenkins, Azure DevOps
📊 Results from teams using Drizz:
⚡ 10× faster test authoring vs Appium
🛠️ 67% less maintenance overhead
✅ 20000+ test cases automated without a single selector
🤝None of this happens without the full Drizz team
Every line of code, every design call, every customer conversation that shaped Drizz, that's the whole team showing up, every single day. Huge love to everyone who's been in the trenches with us. You know who you are. 🧡
🙏 Our ask today
Not asking for upvotes, asking for honest feedback.
→ What does your mobile testing setup look like right now?
→ What would make switching to Drizz a no-brainer for your team?
Drop a comment. We read everyone, and it directly shapes the roadmap.
👉 drizz.dev
Thanks to @rohanrecommends for hunting us, and to the entire Product Hunt community for showing up for builders. Days like today are why we build in public. 🚀
— Yash @yash_varyani , Asad @asad_abrar1 , Zaid @zaid_ahmed_ansari , Zaid @Zaid Abdul Bari, Sreetama @sreetama_chakraborty , Partha @partha_sarathi_mohanty, & the whole Drizz team
Can we test mobile apps on a phone/ mobile OS as well? Something like a TestFlight Log Interceptor or Android equivalent where we can test an app directly on the phone, or is it exclusively for the desktop form factor? Also, are VS-Code compatible IDEs supported?
Congrats on the launch!
Drizz
@koishore
Yes . real device testing is fully supported. You can connect a physical iOS or Android device locally and run tests directly on it, with no SDK or agent embedded in your app. Testers can plug in their actual phone, or use emulators/simulators, and validate flows on real hardware.
On the TestFlight / log-interceptor question - for network-level visibility, network logs from device farms like BrowserStack and LambdaTest are surfaced, so you get that coverage during cloud test runs.
On form factor - Drizz Desktop runs on your computer as the authoring and control surface, while the tests themselves execute on real mobile devices or emulators. So the workflow is: author on desktop, tests run on the phone. And it isn't limited to interactive use - Drizz runs headless in CI/CD, so the same tests execute automatically on every build or pull request, not just when someone's at the desktop app.
On IDE integration - there's no VS Code extension today, but a Drizz CLI is coming, which makes it editor-agnostic out of the box: it runs in any terminal, slots into any VS Code-compatible IDE, and drops straight into CI/CD scripts. So you won't be locked to a specific editor.
Tried Drizz last month after a friend recommended it. Worked surprisingly well on our app — the onboarding tutorial inside the product could use a polish (got a bit lost on step 3) but once you're past that it's smooth.
The team is super responsive on Slack. That counts for a lot this early.
Flexprice
Drizz
@manish_choudhary19 The "let me just buy one more phone" struggle is SO real 😅
You won't need to anymore, Drizz handles all of that for you!
Thanks so much, Manish 💜
"Testing was a tax, not a tool" is a great line, and the 12px button story is painfully relatable. As a fellow builder in the automation space, I love that you went vision-first. Brittle XPaths have wasted more of my life than I'd like to admit.
Congrats on the launch, Yash, rooting for the whole team 🚀
Drizz
@varunrai the vision-first bet gets more interesting from here. Right now the heavy reasoning runs where the compute is, but the direction we're betting on is smaller, sharper models that run on the device itself — testing that's faster because it isn't waiting on a round trip, and more accurate because the model is specialized for screens rather than general-purpose.
Means a lot coming from someone building in the same space — rooting for your work too.
I also liked that it runs on real devices because that’s where most testing issues actually show up 😅.
Congrats to the whole Drizz team on the launch 🚀!