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
What's the point of AI generated comments?
The exact prompt that creates a clear, convincing sales deck
Why can't your target customers always find your product? - Experience sharing
What made me stop building sooner than I used to
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?