There’s no shortage of articles on why teams should adopt PR reviews. Instead of rehashing that, I want to share what’s worked for us at Sphere—a small team of 2 iOS and 2 Android engineers operating in a startup environment where shipping quality features fast is non-negotiable.
I recently pulled the numbers since we migrated from GitHub to GitLab: since May 28th, 4 engineers (mostly 2, since Android only recently moved to our monorepo) merged 257 PRs. That’s roughly 4.28 PRs per day.
What made this possible
Shared architecture patterns
We standardized on common patterns across both our Domain layer (in our shared KMM library) and UI layer (where we use MVI powered by Loop). When everyone knows how a feature is structured, reviewers don’t waste time deciphering code organization.
High trust, low friction
When reviewing, I don’t obsess over algorithm correctness. Bugs can be fixed—especially when features ship behind feature flags. Trust your teammates to write working code.
Approve early
We approve PRs even when comments remain. We only “Request Changes” when a follow-up review is genuinely needed. This is my favorite practice: no more pinging someone to re-approve after addressing minor feedback.
Small PRs
A good PR takes 1-2 minutes to review. We achieve this through stacked branches—once there’s an independent, reviewable chunk of work, open a PR and branch off to continue.
Common mistakes to avoid
Architecture without consistency
A team might claim to use MVVM or MVP, but if every ViewModel or Presenter is structured differently, the architecture label is meaningless. What matters are the concrete patterns: how user input flows, how state propagates to the UI, how views are constructed.
Architecture debates in PR comments
This is probably the most common mistake. By the time code hits a PR, it’s too late for architectural feedback. Complex features that affect the broader codebase need earlier discussion—proposals, RFCs, design spikes, or technical presentations.
Nitpicking
Everyone finds nitpicks annoying, especially when they block approval. Automate style enforcement with linters and formatters. Save human review time for what matters.
Large PRs
Large PRs kill velocity. Reviewers procrastinate on them, reviews happen in fragments, and context gets lost. Break them up.
Adversarial tone
Finally, watch the language in comments. Drop “I” and “you”—it’s about “we” and the team. Code review is collaborative, not adversarial.