Code Review for Tiny Teams (and Teams of One)
REVIEW WHEN YOU'RE ALONE
Hover or focus to flip ↻Code review with five devs, three, or just you: honest coverage targets, a lightweight process that holds, and what replaces the second reader solo.
TL;DR: Most code-review advice assumes reviewer abundance you don't have. The good news from the research: one reader is the bar - Google reviews essentially everything with a median of one approver. On a tiny team, review's knowledge-transfer function matters more than at scale, because every unreviewed merge mints code only one person understands, and you have no redundancy to absorb that. Two devs: review each other, guard against reciprocal stamping. One dev: self-review in the diff view after a break, tools for the mechanical layer, real descriptions as the durable record.
Code-review best practices are written by and for organizations with reviewer pools, rotation schedules, and someone whose job title contains the word "platform." You have four engineers. Or two. Or it's Tuesday night and the whole engineering department is you. The standard advice doesn't scale down gracefully. The evidence behind it does, and it points somewhere encouraging: the review that matters was never the committee. It was one other person actually reading the change.
Does code review even make sense below ten developers?
More than above ten, and here's the mechanism. Review has two products: a quality check and knowledge transfer. Microsoft's research found the measured outcomes of review lean toward the second (knowledge transfer, team awareness, alternative solutions), even though everyone says they review for defects. At scale, an unreviewed change is a quality risk. On a four-person team, it's a structural one: code exactly one person has read is code exactly one person can maintain, and you have no bench. Every skipped review quietly increments somebody's single-owner risk; string enough together and you've built a bus factor of one per subsystem, four subsystems wide.
That's not hypothetical drag, either. In the Stack Overflow 2024 survey, 45.2% of professional developers agree knowledge silos prevent them from getting ideas across their organization. Small teams like to assume they're immune because everyone talks daily. Talking daily about the standup is not reading each other's code. Review is how a tiny team keeps being one team instead of N adjacent solo projects.
And the bar is lower than the enterprise version of the advice implies. Google - reviewer abundance incarnate - reviews essentially every change to its main codebase with a median of one approver, with small changes getting first feedback in under an hour. One reader. That's the whole target, and a two-person team can hit it.
Running review with two to five developers
Lightweight, default-on, with a written fast lane:
- Review-by-default, one approver. Every substantive change gets one other reader before merge. Not two, not a sign-off chain: one. Your review coverage should be a deliberate number rather than an accident of who was busy.
- A written fast lane. Lockfile bumps, generated code, one-line reverts: self-merge allowed, listed explicitly. The list being written is what separates policy from drift, and it keeps the fast lane from swallowing real changes one exception at a time.
- Small PRs, non-negotiable. Review time is a bigger fraction of total capacity on a small team, so make the unit cheap: the Cisco research puts effective review at 200-400 lines at a time, with defect detection collapsing when reviewers race through more. Small PRs make ten-minute honest reviews possible, and ten-minute honest reviews make review-by-default survivable with two people.
- Descriptions that carry the context. With no spare reviewer to absorb ambiguity, the author's PR description does the heavy lifting: why, what, where the risk is, how it was verified. On a two-person team this is also your documentation, whether you meant it to be or not.
- Watch the reciprocal stamp. The failure mode unique to tiny teams: the same two people trading approvals daily until approving becomes a reflex. When speed stops varying with diff size, you've crossed from efficient into approval theater. The counter-ritual is cheap - one deliberately slow review per week, on the scariest change, read at a pace the Cisco data would respect.
What you get to skip, guilt-free: review assignment automation, multi-approver matrices, SLA policies. Those solve routing problems you don't have. A healthy review culture at your size is two norms plus the fast lane in writing: everyone's code gets read, including the founder's, and comments come with reasons attached.
What about a team of one?
Honestly: nothing replaces a second reader, and pretending otherwise would violate the whole premise of this blog. What you can do is approximate the two things a reviewer provides - distance and a different lens - and lay pipe for the day you're not solo:
- Review your own diff, in the diff view, after a break. Open a real PR to yourself and read it in the review UI the next morning. This sounds like ceremony; it isn't. The diff view strips your editor context and shows the change the way a stranger would meet it: the debug line you forgot, the leftover TODO, the function that made sense at 11pm. Distance is a real reviewer property, and sleep manufactures it.
- A written self-review checklist. Error paths, input edges, secrets, migrations reversible, tests actually run. Your recurring mistakes are personal and learnable, so write them down and walk the list. A checklist is a poor reviewer but an excellent skeptic.
- Tools as the mechanical layer. Linters, type checkers, and AI review tools catch the pattern-shaped problems tirelessly. Use them fully, and stay honest about the boundary: they check the code against patterns, never against your intent. The judgment layer is still unstaffed.
- Write the descriptions anyway. The why-what-risk-verified record is what turns your solo repo from a pile of decisions into a legible history. Your first hire will onboard from it. So will you, in eighteen months, wondering what past-you was thinking.
When this needs to grow up
The moment a second person joins, the solo scaffolding converts instantly: the PR habit, the descriptions, and the checklist are already there; you just add the reader. That's the quiet payoff of doing it right while alone. Hiring doesn't require a process migration, only a settings change.
The door for every team size is the same one: this week, make one deliberate pass. Two-plus devs: pick your riskiest open PR and read it at a pace you'd defend out loud. Solo: open your next change as a PR to yourself and read it cold in the morning. One reader, reading honestly. That was always the entire standard.
Frequently asked
Is code review worth it on a small team?
Yes, and arguably more than anywhere else, because the knowledge-transfer half of review is what keeps a three-person team from becoming three bus factors of one. The research consensus is that one reader is enough: Google reviews essentially every change with a median of one approver. Small teams don't need committees; they need the habit of one other set of eyes.
How do you do code review with only two developers?
You review each other's work, with two guardrails. First, keep PRs small enough that review stays a ten-minute habit instead of an afternoon tax. Second, watch for reciprocal rubber-stamping: when the same two people trade instant approvals daily, depth erodes quietly. A periodic slow pass on the riskiest change of the week keeps the habit honest.
How do you review code as a solo developer?
You can't replace a second reader, but you can approximate the distance one provides: open a PR to yourself and review the diff in the review UI after a break; reading the diff view genuinely catches things the editor didn't. Add a written self-review checklist, let automated and AI review tools flag the mechanical issues, and write real PR descriptions: they're the record a future collaborator (or future you) will read.
When should a startup make code review mandatory?
Before it feels necessary. The cheapest moment is when the team is small and the norm is easy to set. Every unreviewed merge on a five-person team creates code exactly one person understands, and the cost arrives later as onboarding drag and single-owner risk. Set review-by-default with a written fast-lane for trivial changes from day one.