When to Get an External Code Review: 9 Clear Situations

Get an external code review when a costly or risky decision rests on code that no independent developer has looked at. In practice, knowing when to get an external code review comes down to nine moments: inheriting a codebase, raising money or selling, funding a big build, launching an AI-built app, and a handful of situations where something has broken or stalled. What you want out of it is a short, prioritized report you can act on, not a grade for your developer.

I'm a freelance full-stack developer based in Denmark, and reviewing code I didn't write is part of my work, so factor that in. It's also why there's a section on when you can keep your money.

The short answer

Here are the nine situations, the question a review should answer in each, and when it should happen.

My rule of thumb: the more money or code you're about to stack on top of an existing system, the earlier it should be reviewed. A review is one piece of keeping a live app healthy, and I've covered the rest in my complete guide to web application maintenance.

What an external code review covers (and what it doesn't)

An external code review, also called a code audit or third-party code review, is a structured look at your code, your infrastructure setup and your development process by a developer who didn't write it and has no reason to defend it. Think of it as a pre-purchase inspection on a used car: you learn what's sound, what needs fixing soon and what can wait.

A thorough review usually covers:

• Setup: can the project be run from what's in the repository, and do you control every account and credential?
• Versions and dependencies: are the framework, the language and the packages still getting security updates?
• Security: authentication, access control, input handling and secrets. The open OWASP Application Security Verification Standard (ASVS) is a solid reference for this part.
• Architecture and data model: can the system grow without a rebuild?
• Tests and deployment: are there automated tests, and can a bad release be rolled back?
• Operations: backups, logging and monitoring.

It isn't the same as the pull request reviews developers on a team do for each other every day. Those look at one change at a time, while an external review looks at the whole. It isn't a penetration test of your web app either, where someone tries to break into the running system from the outside, usually without reading the code.

And it's more than running a scanner. Tools like PHPStan, composer audit and npm audit catch known patterns and vulnerable packages, but they can't tell you whether your business logic is right or whether the architecture fits your next stage.

When a big decision is on the table

The first three situations share one thing: a large commitment is coming. A review is cheap compared to what it can save you here.

1. You're inheriting a codebase from another developer or agency

Switching developers, or picking up the pieces after a supplier has vanished, usually means you don't know exactly what you own. Code might be missing from the repository, production might run a different version from the one in Git, and features you paid for might be half built.

Get the review done before the new developer changes anything. It gives everyone a shared baseline and makes it obvious which problems were inherited and which came later. The handover itself (access, contracts and documentation) is covered in my guide on how to switch developers mid-project.

2. You're investing in, buying or selling a software business

When software is a large part of what changes hands, the code is part of the price. Investors and buyers want to know whether the product can handle growth, whether a large technical debt bill is hiding in it, and whether everything depends on one person. The technical half of due diligence is, in practice, a code review with a sharp focus on risk.

Expect questions about whether the company controls all code and accounts, whether open source packages carry licenses that clash with a commercial product, and what it would cost to bring the system up to a defensible standard. Have a lawyer look at ownership and licensing too. A developer can find the issues in the code but can't assess the contracts.

If you're the seller, flip it around and commission the review before the buyer does. You can then fix the worst findings calmly instead of conceding on price under deadline pressure.

3. You're about to fund a major build

A new module, a mobile app, a move into new markets or many more users: all of it sits on top of what already exists. If the foundation is off, every new feature costs more, and you tend to find out after much of the budget is gone.

A review beforehand answers three questions: can the data model and architecture carry the plan, what needs fixing first, and does the estimate hold up? A few days of review is usually small next to a project that runs for months, which is why this is where a review pays off most clearly.

When the risk is invisible from the outside

The next three situations involve systems that look fine on the surface. The problem is that you can't see what's underneath.

4. Your app was built with AI tools

Lovable, Bolt, v0 and Cursor can produce something that looks finished in days. The trouble is what you can't see: whether one user can read another user's data, whether secret keys are exposed in the browser, and whether backups exist at all. Veracode's 2025 GenAI Code Security Report tested more than 100 language models and found that 45% of the code samples introduced vulnerabilities from the OWASP Top 10, the most widely used list of common web app security flaws.

That doesn't make AI-built apps worthless. It means they need a review before real users, payments or personal data come in. The review also settles the big question: can the app be cleaned up, or is it cheaper to rebuild it on a foundation someone can maintain?

5. You can't judge the work you're paying for

Plenty of founders and managers pay an agency, a contractor or an offshore team every month without being able to read the code themselves. That's fine while things work. But when estimates keep growing, the same bugs keep coming back, or you don't have access to your own repository, you have no way to tell whether the problem is the code, the process or the supplier.

An independent review gives you a baseline, and it isn't an accusation. Good developers don't mind a second pair of eyes. If your supplier refuses to let anyone else see the code, treat that refusal as a finding in itself.

It's just as relevant when the whole system depends on a single person. The review shows how hard it would be for someone else to take over and what needs documenting to reduce that dependency.

6. A customer or regulator wants proof

Sell software to larger companies and sooner or later a security questionnaire lands in your inbox. In the EU, many of those customers fall under the NIS2 Directive, which requires them to manage security across their supply chain, including their relationships with suppliers like you. They pass that pressure straight down.

If your system processes personal data, Article 32 of the GDPR also lists a process for regularly testing, assessing and evaluating whether your security measures work. It's one of the measures you're expected to have where appropriate, and the GDPR can apply to companies outside the EU that offer services to people in it. A review with a written report and a plan for the fixes is a concrete way to show you do this. This isn't legal advice, so check your specific obligations with a qualified advisor.

When something has broken or stalled

The last three situations usually show up after a stretch with nobody watching the system, or when a crisis forces your hand.

7. After an outage, a breach or a serious bug

When the app is down or data has leaked, the first hours are about containment. If you need a playbook for that part, start with what to do when your website or app is down. Once things are stable, one question remains: was this a one-off or a symptom?

A post-incident review looks for the root cause and for the same weakness elsewhere in the code. If a missing access check exposed other customers' data in one place, it's rarely the only place. When personal data is involved, you may also have to notify your data protection authority, and a technical review helps you explain what happened and what you've done about it.

8. The system has sat untouched for years

Lots of systems run for years without anyone touching them. As long as nothing needs to change, nobody notices that the framework, the language version and the packages stopped getting security patches long ago. According to PHP's supported versions page, PHP 8.2 and everything older receive no security fixes after December 31, 2026.

If development is about to restart, or a new developer is taking over, a review is the first step. It maps how far behind the system is and which updates to tackle first. I've explained why that bill grows the longer you wait in my post on why you should keep software dependencies updated.

9. Someone proposes a rewrite

It's common for a new developer or agency to look at an existing system and recommend rebuilding it from scratch. Sometimes they're right. But building your own thing is easier than understanding someone else's, and a rewrite is a big contract for whoever pitches it. That applies to me too.

Before you agree to a project that almost always runs longer than planned, get an opinion from a developer who won't be doing the rewrite. The question isn't whether the code is pretty. It's whether cleaning it up and replacing it piece by piece would cost less. I've described that route in my post on legacy PHP modernization.

When you can skip the review

A review costs money, and not every system needs one. You can usually skip it when:

• Your website runs on WordPress or another standard CMS with very little custom code. Updates, backups and decent hosting matter more than a code review.
• The app is a prototype for testing an idea, with no real users, payments or personal data.
• You won't act on the findings. A report that sits in a drawer is wasted money, so spend it on the problem you already know about.
• You have an experienced team that reviews each other's code, runs automated tests and keeps dependencies current. A targeted security test is often more useful than a broad review.
• What you actually need is a formal certification such as ISO 27001. A code review can support that work, but it doesn't replace the certification audit, so start there.

One honest caveat: I review systems built with Laravel and PHP, and JavaScript stacks such as React and Next.js. If yours is written in .NET, Java or Python, find a reviewer with deep experience in that stack.

How to get a review you can actually use

A review is only as good as the question it's meant to answer. Here's how to set it up:

1. Name the decision. "Should we build on this or start over?" gets a far more useful answer than "Is the code good?"
2. Set the scope. The whole system, or only the critical parts such as login, payments and access to customer data?
3. Grant the right access. The reviewer needs the repository and ideally a staging environment (a test copy of the app). Avoid sharing real personal data, and if you can't avoid it, sign a data processing agreement first.
4. Ask about conflicts of interest. A reviewer who'd like the follow-up work has an incentive. That doesn't disqualify them, but the report should be usable by any developer.
5. Book a walkthrough of the report so you can ask about anything you don't understand.

Next steps

Pick the situation on the list that fits you best and write down the decision the review should support. Then gather repository access, a short description of the system and the three things that worry you most. With that in hand, a competent reviewer can give you a realistic scope and price.

I agree on scope and price before I start, and my approach is that the report should be usable by any developer, even if I'm not the one doing the fixes. You deal directly with the person reading your code, in a time zone that fully overlaps UK and EU business hours. You can see how I work with existing systems on my maintenance and development service page.

Frequently asked questions

How much does an external code review cost?+

It depends mostly on the size of the codebase, the number of integrations, and whether the review covers everything or only security. As a rough guide, a small app takes a few days of work and a large platform can take a couple of weeks, so the price follows the reviewer's day rate. Ask for a fixed price on a clearly scoped review so you know the cost before you get the answer.

Should I tell my current developer about the review?+

Usually, yes. The review gets better when your developer can explain the decisions behind the code, and fixes go faster when the person who knows the system is involved from the start. Make it clear that the code is being assessed, not the person. If the relationship has already broken down, it can be reasonable to get the assessment first and have the conversation afterwards.

Can't an AI tool just do the code review?+

Partly. AI assistants and automated scanners are good at spotting known patterns, vulnerable packages and obvious mistakes, and they belong in any thorough review. What they can't do is judge whether the business logic is right, whether the architecture suits your plans, or which findings matter for your company. Use them as a supplement to an experienced developer, not a replacement.

How often should you get a code review?+

For most systems, at the moments described in this post rather than on a fixed calendar. If you handle sensitive personal data or sell to customers with strict security requirements, a yearly review, or one before major changes, is a sensible habit. Between reviews, regular updates, automated tests and monitoring do most of the work.