Introduce yourself
Say hello to the Product Hunt community
Start new thread
Yagnik Kantaria

Introducing myself — building a small tool to reduce QA ↔ Dev back-and-forth

by•

Hey Product Hunt 👋

I’m a mobile developer with 6+ years of experience, mostly working with Flutter across mobile and desktop.

Over the years, I kept seeing the same issue repeat across teams:
QA reports a bug, developers can’t reproduce it, and a lot of time is lost just trying to understand context.

On top of that, QA often has to jump between multiple tools just to create a single task — screen recorder, screenshot tool, notes, issue tracker — which breaks flow and still leaves gaps in information.

So I decided to start building a small cross-platform utility (macOS, Windows, and mobile) focused on making bug reporting clearer and faster for both QA engineers and developers.

To be clear, I’m not building another task or issue-tracking tool.
The goal is to reduce the friction before a task is created, by capturing better context upfront.

Right now, I’m early and intentionally keeping the scope small.
I’m focusing on one core capability: capturing the screen and automatically attaching useful context to reduce follow-up questions.

I’m not launching yet — just sharing early progress and learning in public.

If you’ve worked in QA or development teams:

  • What’s the most frustrating part of bug reports for you?

  • What context do you always wish you had upfront?

Would love to learn from this community 🙏

16 views

Add a comment

Replies

Best
Ismaila Adamu

The biggest pain for me is missing context steps to reproduce, environment, and what the user expected to happen. If your tool can auto-capture screen + device info + logs and bundle it cleanly, that alone removes 80% of QA ↔ Dev back-and-forth. Excited to see where you take it!

Yagnik Kantaria

@ismaila__adamu 
Thanks — this is exactly the pain that pushed me to start building this. You’ve described the QA ↔ Dev gap perfectly.

You’re right that auto-capturing screen + device + environment context can eliminate a huge amount of back-and-forth. Long-term, that’s absolutely the direction I believe bug reporting needs to go.


That said, I’m being very intentional about the first release. Right now, the focus is narrower: capturing the screen reliably and attaching just enough structured context to make reports actionable, without overwhelming QA or devs with noise.

I
’ve seen tools try to do everything upfront and end up hurting adoption. I’d rather earn trust by solving one painful part well, then expand based on real usage.

Curious from your experience — when a bug isn’t reproducible, what’s the single missing piece of context that blocks you most often: environment, user intent, or state before the issue?