The Freelancer Who Made Me Wait Three Days
A client called me a few years ago, frustrated. He had hired a freelance developer to build a discount calculator for his online store. The code was done. It worked in testing. But the freelancer said he wanted "one more day" for a colleague to review it before it went live.
My client was annoyed. He was paying by the hour, and this felt like paying someone to sit around reading someone else's work. He asked me if that was normal, or if he was getting taken for a ride.
I told him to let the review happen. Good thing he did.
The reviewer found a rounding error in the discount logic. Under one specific combination of coupon and quantity, the calculator applied the discount twice. Customers with the right cart would get double the discount the store meant to give. Nothing would have crashed. No error message would have appeared. The store simply would have quietly lost money on every order that hit that combination, for as long as it took someone to notice.
That one day of "sitting around" saved my client real money, possibly for months.
What a Code Review Actually Is
A code review is simple: before new code goes live, a second developer reads it. They are not just checking that it runs. They are checking whether it does the right thing, in every situation a real customer might create.
Think of it like sending a contract to a second lawyer before you sign it. The first lawyer wrote something that works. A second set of eyes checks it for the traps the first one might not have thought to look for, because writing something and checking something use different parts of your brain.
That is the whole idea. One person builds. Someone else checks. It is not bureaucracy. It is the same reason a second person proofreads an important email before you send it to your entire client list.
What a Second Pair of Eyes Catches That Tests Miss
Business owners often assume that if software "passes testing," it is safe. Testing matters, and I have written about why automated testing is worth the investment. But tests only check the situations someone thought to test for. A code review catches a different kind of problem: the one nobody tested, because nobody imagined it would happen.
A reviewer reads the logic itself, not just the result. That is how they catch things like:
- Bad assumptions. The original developer assumed every customer address would be inside the country. The reviewer knows the store ships internationally and asks what happens when it isn't.
- Security gaps. The code accepts a file upload without checking what kind of file it is. A reviewer with security experience flags that before it becomes a way for someone to upload something dangerous.
- Unclear logic that will break later. Code that works today but will quietly fail the next time someone edits it, because it was never clear what it was supposed to do in the first place.
None of these show up as an error message. They show up as a slow leak: wrong charges, exposed data, or a feature that breaks six months from now, when nobody remembers why it was built that way.
The discount calculator is a good example. Automated tests would only have caught the rounding error if someone had thought to test that exact combination of coupon and quantity. A single developer, focused on making the feature work, is unlikely to invent every edge case a real customer will stumble into by accident. A second developer, reading the logic with fresh eyes and no attachment to the original approach, is far more likely to ask "what if someone does this?" — and that question is worth more than any amount of extra testing after the fact.
Why "Slower" Often Means "Cheaper"
Here is the part that is hard to see when you are watching a clock and a budget: catching a mistake before it reaches your customers is almost always cheaper than catching it after.
Before launch, fixing a mistake means changing some code. After launch, it means changing the code, plus refunding customers, plus explaining to someone why their order was wrong, plus rebuilding trust. Research on software defects shows the same pattern again and again: the earlier a mistake gets caught, the smaller the cleanup. A code review is one of the cheapest points in the whole process to catch one, because nothing has shipped yet.
The extra day my client's freelancer asked for did not slow the project down. It prevented a much bigger delay later: the one where the store has to pause, investigate a billing problem, and rebuild customer trust.
The Knowledge Problem No One Talks About
There is a second benefit that has nothing to do with bugs. When only one person has ever looked at your code, only one person understands it. If that person is unreachable, on vacation, or gone, you are stuck. I have written before about what happens when a business depends on one person who understands how everything works — a solo freelancer with no review process is exactly that risk, built into your software from day one.
A code review means at least two people understand how your system works. That is not a nice-to-have. It is insurance.
One Question to Ask Any Developer You Hire
If you are working with a solo freelancer, or a small shop, ask this before the project starts: "Who reviews your code before it ships?"
A confident answer sounds like: "I send it to another developer," or "I use a service where a second engineer checks critical changes." A weak answer sounds like: "I test it myself," or, worse, silence.
You are not trying to catch anyone doing something wrong. You are trying to find out whether a second set of eyes will ever look at the code that runs your business. If the answer is no, you are the only safety net. That is a real risk, and it is worth weighing into your decision.