Code review for small teams is a different beast to the version described in most blog posts. Those articles assume dozens of engineers, strict branch policies and a dedicated platform team. I have spent 17 years building software, mostly in teams of one to five, and the advice rarely survives contact with reality.
So here is what I actually do. It is lighter, more opinionated and a lot less ceremonial. But it has caught real bugs before they reached customers on products like CampSuite.
Why code review matters even when you are tiny
The usual reason given is catching bugs. That is true, but for a small team the bigger benefit is shared knowledge. If only one person understands the billing code, you do not have a billing system. You have a single point of failure with a pulse.
Review is also the cheapest training you will ever run. A junior who has their code read properly by someone experienced learns faster than from any course. And the reviewer learns what the rest of the system is doing, which is half the battle in a growing codebase.
Keep pull requests small or do not bother
The single biggest factor in whether a review is any good is the size of the change. Nobody properly reviews 1,500 lines. They skim it, say "looks fine" and hit approve, and you have just wasted everyone's time.
My rule is simple. If a pull request cannot be understood in about fifteen minutes, it is too big. Split it. Refactors go in one pull request, behaviour changes in another, and never the two together.
This is also where feature flags earn their keep. You can merge half finished work safely behind a flag, so you are not forced into one monster branch that nobody wants to read.
What a reviewer should actually look at
Do not waste human attention on things a machine can check. Formatting, naming conventions, unused imports and basic style should be handled by your linter and formatter in the build. If a person is arguing about brace placement, your process is broken.
Spend your attention on the stuff only a human can judge. I look at these things, in roughly this order.
Does it solve the right problem?
Before reading a single line, read the description. If the change does not match what was asked for, no amount of clean code saves it. I would rather find this out in two minutes than twenty.
Is it safe?
Authorisation checks, input handling, anything touching money or personal data. These are the bits where a mistake costs you a customer or a fine. I slow right down on these and speed up everywhere else.
Will it hurt at 2am?
Is there logging when it fails? What happens if the third party API is down? Does it fall over with ten thousand records instead of ten? Production problems rarely come from the happy path, so review the unhappy one.
Can someone else maintain it?
If I cannot work out what a function does in a reasonable time, the next person will not either. A comment explaining why something odd exists is worth far more than a comment saying what the code does. This is how you keep technical debt from quietly piling up.
Code review as a solo developer
Yes, you can review your own code. It just takes a bit of discipline. I always open the pull request on my own work, even when nobody else will see it, and read the diff as if a stranger wrote it.
It is remarkable what jumps out. Debug statements, a half removed feature, a variable name that made sense at midnight and now looks daft. Reading the diff in the browser rather than in your editor changes how your brain treats it.
A few other habits help. Leave the change overnight if you can, then review it fresh in the morning. Keep a short checklist of the mistakes you personally repeat. Mine includes missing null checks, forgotten database indexes and error messages that tell the user nothing.
If you can afford it, pay for an occasional outside review of the risky bits. A few hours of an experienced developer reading your authentication or payment code is cheap insurance. It is one of the things I do for clients through my development consultancy.
Use AI review, but do not hand it the keys
AI tools are genuinely useful as a first pass. They are good at spotting obvious bugs, missing edge cases and inconsistent patterns, and they never get tired or grumpy. I wrote more about this in my post on AI coding tools and developer productivity.
But they do not know your business. They will not tell you that a perfectly tidy change breaks a promise you made to a customer last year. Treat the AI as a keen but slightly naive colleague, not as the approver.
Make reviews fast or people will route around them
The quickest way to kill code review is to let pull requests sit for three days. People get frustrated, start batching work into bigger changes, and eventually stop asking. Then you have no review at all and a nicely worded policy saying you do.
Set a simple expectation. Reviews get looked at the same working day, even if it is only a first pass. Blocked work is far more expensive than a slightly imperfect review.
Be kind, be specific
Tone matters enormously in a tiny team, because you have to work together tomorrow. Say "could this return early here?" rather than "this is messy". Separate the things that must change from the things that are just preferences, and say which is which.
Also approve things. A review that is nothing but criticism teaches people to avoid you. If something is clever or tidy, say so.
A simple setup you can start this week
You do not need a heavy process. Here is the lightweight version I recommend to the small teams I work with.
- Protect the main branch so nothing goes straight in.
- Run the build, tests and linter automatically on every pull request.
- Require one approval, from anyone who understands the area.
- Keep changes small enough to read in fifteen minutes.
- Review your own diff first, every time.
That is it. Start there, and only add rules when a real problem demands one. Process that nobody asked for is just another thing to maintain.
Good review is mostly habit, not tooling. Get the habit right in a team of two and it scales naturally as you grow. Get it wrong and no amount of expensive software will rescue you.
