PRBoard
Finally, a way to see all your PRs without losing your mind
The first Monday it showed up in Slack, someone called it cringe.
A simple leaderboard. Names, points, review count. Posted automatically every week at 9 AM. I had added it almost as an afterthought, not really expecting it to do anything.
The second Monday, nobody said anything. But I noticed something in the data. The person who called it cringe had reviewed four pull requests that week. The week before, he had reviewed zero.
I did not say anything either.
By week three, people were checking it mid-week. Not obsessively. Just a quick glance before picking up new work. Someone who had been reviewing once or twice a month was suddenly showing up every few days. Not because anyone asked. Just because they could see where they stood.
Here is what I think happened.
The problem was never that engineers did not care about reviews. It was that review work was invisible. You could do five thorough reviews in a week and nobody would know. You could do zero and nobody would know that either. When work is invisible it does not get done consistently. Not because people are lazy but because humans respond to feedback loops. No feedback loop, no consistent behavior.
The leaderboard did not create motivation. It created visibility. And visibility created the feedback loop that was missing.
Review rate went from 60 percent to 94 percent in 8 weeks. First review time dropped from 4.5 hours to under 45 minutes. The team did not change. The codebase did not change. The only thing that changed was that people could see who was carrying the load and who was not.
There were rough edges. Someone gamed it early on by leaving one word comments to rack up points. We fixed the scoring. Someone else got competitive in a way that felt unhealthy for a week. It settled down on its own once the novelty wore off.
What stayed was the habit. Reviews became a thing people just did, like responding to messages or updating tickets. Not a favor you asked for. Not a blocker you chased. Just part of the workflow.
We turned this into PRBoard. One board for every open pull request. Smart routing that sends one Slack DM to the right reviewer based on workload and code familiarity. The leaderboard is built in. SLA alerts fire before pull requests go stale. Review time on teams using it sits at 43 minutes on average.
Free for teams of up to three people. No credit card needed.
If your standups still have the "did anyone look at my pull request" moment, this is worth ten minutes.
What changed your team's review culture? Curious what worked for others.
Two weeks ago I was sitting at my desk, copy-pasting the same Slack message for the third time that week.
"Hey, can you review this PR when you get a chance?"
Nobody responded. The PR sat there for another day. The feature was ready, the code was written, but nothing was moving because one review was pending, and I had no idea who was supposed to do it or if they had even seen it.
That was the moment I decided to just build the thing I actually needed.
PRBoard is a simple board that displays all open pull requests across your team. Who opened it, who needs to review it, and how long it has been waiting. No emails. No Slack pings. No chasing.
I have been building it for 10 days. It is rough around the edges, but it already solved my own problem, so I figured someone else probably has the same one.
If your team loses hours every week just trying to get PRs reviewed, I would love for you to try it.
-
1
This is exactly what happens on our team every single week. The PR is done but it just sits there waiting for someone to notice it. Bookmarking this.
-
1
Exactly that feeling. The worst part is everyone is busy, nobody is ignoring it on purpose, there is just no shared view of what is waiting. That is literally why I built this. Hope it saves your team some time, would love to hear how it goes.
-
8 Comments
This works because visibility is cheaper than authority. The dark side most leaders don't think about: whatever you put on a leaderboard becomes what people optimize for, sometimes at the cost of what actually matters. PR review counts can drift into rubber-stamped approvals if nobody is measuring review quality. The teams I ran for almost 20 years had the same pattern with ticket close rates. People closed faster, sometimes by closing wrong.
Curious if you have added any signal for review depth (comment count, follow-up rate, regression incidents tied to a review) before this scales beyond your own team.
This is exactly the thing I worried about most.
We hit it in week two. Someone figured out that leaving any comment counted as a review. One word replies, rubber stamp approvals. We caught it because merge quality dropped noticeably on those PRs, more revision rounds, a couple of small regressions that should have been caught earlier.
So now points are weighted. A review that triggered zero follow up from the author scores lower than one that started a real back and forth. We also track what happens after the merge. If a PR gets waved through and then causes problems, that reviewer's score reflects it.
Still gameable by someone determined enough. But I think the leaderboard was never supposed to replace judgment, it just makes invisible work visible. The quality layer is what gives it teeth.
Your ticket example is exactly why a raw count alone is just pressure with a scoreboard attached. Context is what turns it into an actual feedback loop.
Genuinely curious what signal you found most predictive of review quality over those 20 years. Regression rate per reviewer, or something else entirely?
Hey Vinay,
Spent ~10 min on prboard, nice work. The “without annoying your developers” framing is doing a lot of heavy lifting, one of the good B2B hooks I’ve seen.
One small thing I noticed: the demo tabs (Board / Routing / Slack) don’t feel obviously interactive — devs scanning fast might miss them. Feels like a small tweak could unlock a lot of value there.
Happy to share a couple more things I’d tighten if useful.
— Jitesh (Product designer @ Microsoft, currently obsessed with AI-product UX)
Story is well-written, "visibility creates feedback loop" is sharp.
Three things worth pushing though.
Leaderboard incentivizes count, not quality. 20 fast surface-level reviews ranks higher than 5 deep ones that catch bugs. You fixed one-word gaming, but the asymmetry remains — deep reviews are slower and rarer. Leaderboard may select against highest-leverage work.
94% review rate hides selection bias. Teams adopting PRBoard already care about reviews. Lift partially from tool, partially from self-selecting team, partially from Hawthorne effect. The 60% → 94% is real but less PRBoard-attributable than implied.
Category is crowded too. GitHub native + assignees, Graphite, CodeRabbit ($10M AI review), Linear + GitHub, internal scripts. Your wedge is a bundle of pieces that exist elsewhere. Bundles compete with best-of-breed.
Pricing path — Free for 3 + Pro/AI "coming soon" means traction story, not revenue model yet.
Fair points, genuinely. Let me go one by one.
Quality vs quantity: You are right, count-based scoring selects against deep work. That is why we weight by PR size, comment depth, and whether changes were requested. Not perfect yet, still tuning. The one-word exploit was the obvious fix. What you named is the subtler and harder problem.
94% figure: I am not going to oversell it. Self-selecting teams, Hawthorne effect, both real. What I can say is the teams that went quiet after week two still held the number. Novelty wore off, habit stayed. I think that is meaningful, but I take your point that I cannot fully separate the tool from the team.
Competition: GitHub native assignment is manual or random. Graphite is stacked PRs, different problem. CodeRabbit is AI line-by-line review, also different. Our gap is routing plus visibility plus Slack in one place without stitching three tools together. Bundles lose to best-of-breed when the pieces are far apart. These pieces sit right next to each other in the same workflow.
Revenue: Fair. Traction first, paid coming soon. That was a conscious choice, not an accident. Appreciate you pushing on it.
The competition rebuttal is genuinely sharp — you turned the bundle critique into a cleaner articulation of your wedge. "Bundles lose when pieces are far apart, but these sit next to each other in the workflow" is a real positioning line. Lead with it.
Two extensions.
Quality weighting — PR size, comment depth, changes-requested are still proxies, not quality. A long comment on a trivial change scores high. Review quality is only knowable downstream (did it catch a bug that would've shipped). So the defensible claim is the leaderboard drives consistency (clearly does), not quality (can't measure). Consistency is the more honest pitch.
The wedge — "three pieces in one workflow" is real but easy for GitHub to copy. Durable moat isn't co-location, it's routing logic that's hard to replicate. Bundle is the wedge; routing intelligence is the moat.
This kind of pressure-testing is what we built HiveMind for (myosin.xyz/hivemind, code HivemindIH123).
This actually makes a lot of sense. Review work being invisible was always the real problem, not people being lazy. Once you can see where you stand, behavior changes on its own. Going to check out PRBoard, thanks for sharing this.
Really glad it landed that way. You nailed the insight exactly. It was never a motivation problem, it was a visibility problem. The moment people could see the distribution, they self-corrected without anyone having to say anything. Hope PRBoard works well for your team, would love to hear how it goes.