Looking for a few engineers to help test a lightweight PR review tool
Hey folks đź‘‹
I’m one of the founders of Hikaflow. We’re building a lightweight tool that acts as a second pass on pull requests, helping with code review, testing signals, and other repetitive engineering checks, especially for individuals and small teams.
We’re at a stage where the product is ready, but instead of launching broadly, we want to learn directly from real engineers working on real code.
Right now, we’re looking for:
- Solo developers or small teams
- Active GitHub projects (public or private)
- People who use PRs regularly and move fast
This is not a pitch, and there’s no obligation. The goal is simply:
- You try it on a real PR
- We see what works, what doesn’t
- You give brutally honest feedback
If this sounds interesting, comment here 'Interested', happy to share more context or answer questions.
Appreciate this community a lot, and excited to learn from you all.
Trending on Indie Hackers
PR review tooling is genuinely one of those workflows where small friction losses stack up fast — context switching from code → review UI → comments → diff view is surprisingly costly in cognitive load.
Curious — as you’re thinking about testing, are you focusing on specific behaviors like:
• reducing time to give a first review pass
• reducing the total number of context switches per PR
• or improving clarity of review comments (less rework)
Tools can look elegant in isolation, but what developers really care about is whether they reduce real friction in daily code reviews. What signal(s) are you watching first to decide this tool is actually helping?
Ideally, it allows teams to reduce their Code Review, Testing, and Debugging time from days to minutes. By the way, here is a link: https://app.hikaflow.com
Why don't you try it in your workflow and share anything you find meaningful?
That makes sense as the long-term goal.
When you’ve had engineers test it so far, what’s been the first concrete signal that told you “this is working”?
For example:
I’ve found those early behavioral shifts usually show up well before dramatic time reductions.