Launching today
Drizz
Mobile tests that write, run, and fix themselves
129 followers
Mobile tests that write, run, and fix themselves
129 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.
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.
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.
Drizz
Try Out Drizz right here, we are giving free launch day credits: https://www.drizz.dev/download-desktop-app
Bugasura
Complexity of the world is growing and we need more than just one test solution. As a fellow builder of AI Testing tools and Tools to Test for AI - I like the approach of Drizz. Running tests on mobile was already harder in the pre-AI world and I wish Drizz makes it easier for all of us. Best wishes team Drizz.
Drizz
@pradeepsoundararajan Means so much coming from a builder, Pradeep 💜
You're so right, one tool will never solve all of it. Mobile QA was already wild pre-AI, now there's a whole new layer. Rooting for Bugasura too!
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!