Most code review advice on the internet was written by people working in teams of fifty. Code review at three engineers is a different game with different rules, and applying the big-team playbook to a tiny team is one of the most common process traps I see at seed stage.
The goal of code review at three engineers isn’t compliance, gatekeeping, or quality assurance. It’s shared context. If you optimize for the wrong goal, you get a process that slows your team down and doesn’t actually improve the code. If you optimize for shared context, you get something fast and useful that grows with the team.
What Big-Team Code Review Is For
In a fifty-person engineering organization, code review serves several purposes that have nothing to do with the code itself: defending against rogue commits, distributing knowledge across people who don’t talk to each other, enforcing standards that not everyone has internalized, gating compliance and security checks. Those problems are real at scale. They’re not your problems yet.
When you import that process into a three-person team, you import the slowness without the benefits. You end up with PRs that wait two days for review, three rounds of nitpicks on a four-line bugfix, and a team that quietly stops opening PRs and starts pushing to main “just for this one.”
The Three-Engineer Rules
Here’s the lightweight code review process I recommend at three engineers, give or take:
The five-minute rule. If a PR isn’t reviewed within five minutes of being opened, you’re either both too busy to be reviewing it carefully, or the work isn’t atomic enough. Either way, the right move usually isn’t “wait longer.” It’s “ping the other person and review together for two minutes.” Synchronous beats asynchronous at this size.
Skip review for trivial work. Typo fixes, dependency bumps, copy changes, configuration tweaks — none of these need a review at three engineers. They need a green CI and a push. Reserve the review ritual for changes that affect the data model, the API surface, or shared abstractions. Everything else can be a direct push if you trust each other.
Pair on tricky stuff before the PR exists. The best code review at three engineers happens before any code is written. If something is hard, ambiguous, or scary, hop on a call for fifteen minutes and sketch it together. The PR that comes out of that conversation needs almost no review, because the review already happened.
Comment lightly. Push back rarely. A small team needs to ship. The cost of a back-and-forth on style preferences is much higher than the cost of inconsistent style for a few months. Save your strong opinions for the things that actually matter — security, data integrity, future flexibility — and let the rest go.
What to Actually Look For
When you do review code seriously at three engineers, you’re not looking for the same things a senior reviewer at a big company looks for. You’re looking for two things specifically:
Are we going to regret this in three months? Most of your code is throwaway. A small fraction of it is going to be load-bearing for a long time. The reviewer’s job is to flag the load-bearing parts and make sure they’re at least defensible — clean separation, no premature abstractions, an obvious place to extend later.
Do we both understand it now? The other reviewer reads the PR not to bless it, but to learn it. If the reviewer can’t explain what changed and why, the PR isn’t done. Not because of the code, but because the team’s shared mental model is now incomplete. This is the real value of code review at three engineers — keeping everyone in sync on what the codebase is doing.
When to Add Stricter Process
The honest answer: you’ll know. Around five to seven engineers, the lightweight version starts breaking down. People stop being in each other’s heads. Knowledge gets compartmentalized. The five-minute rule no longer works because everyone’s in a meeting. That’s the moment to add structure — required reviewers, branch protection, a CODEOWNERS file, more rigorous review templates.
Don’t preempt it. Adding structure too early is the most expensive process mistake I see seed-stage teams make. The structure is supposed to relieve a pain you’re already feeling. If you’re not feeling the pain, you don’t need the structure. Lead with trust, add process when the trust starts breaking, not before.
The Meta-Principle
Engineering process at seed stage should always answer the question: “what’s the smallest version of this that solves a problem we’re actually having today?” Not the version that scales to fifty engineers. Not the version your last company used. The smallest version that works now, with the team you have, on the problem you’re actually facing. Process can grow. Process you outgrow is healthy. Process you preemptively install almost never gets removed, even when it’s actively hurting you.
Let’s Talk
If your engineering team is small and you’re not sure whether your process is helping or hurting, this is the kind of question I work through with founders all the time. The right answer for three engineers looks nothing like the right answer for thirty, and the gap between them is where most early-stage teams accidentally slow themselves down. Reach out and let’s tune it.
