When a Client Hires a Developer to Review Your Code (Handle It Without Getting Defensive)

The Short Answer

When a client hires a developer to review your code, say yes quickly and calmly, make the reviewer's job easy, and ask for their findings in writing so you can respond to each one. Then sort every finding: real bugs and security issues you fix, matters of taste you discuss, and requests for new things you scope and price. Do not argue line by line in a group chat, and do not treat the reviewer as an opponent. The client is watching for one thing - whether you are confident in your work and open about it.

That is the Second Opinion Playbook. It works because a review is only a threat to a builder who has something to hide. If your build is solid and documented, a second developer confirming that is the best reference you will ever get, and it comes from someone the client already trusts.

Why Clients Bring In a Reviewer

Before you reply, work out which of these is behind it. The tone of your response changes depending on the reason.

• They cannot judge the work themselves. Most clients are not technical. A review is how they check that what they paid for is sound before they rely on it.
• Someone above them asked. An investor, a board member, a partner, or a new technical hire wants an independent look before more money goes in.
• They are planning to take it in-house. A developer they are about to hire, or already have, needs to understand the build before owning it. [When a client wants to hire in-house instead of you](/blog/client-wants-to-hire-in-house-instead-of-you) covers that conversation.
• Something went wrong. A bug in production or a slow page made them nervous, and they want to know whether it was a one-off or a sign of deeper problems.
• They heard it was built with AI. If a client learns the build was made with Claude Code and you never explained how you check the output, a review is a reasonable reaction. [Should you tell clients you use AI](/blog/should-you-tell-clients-you-use-ai) is the conversation that prevents this one.

Notice that only one of these is about you doing something wrong, and even that one is often just nerves. Treat every review as the first four until the findings prove otherwise.

Run the Second Opinion Playbook

Reply the same day, in writing, and keep it short. Cover these five things.

1. Welcome it. Say plainly that you are glad they are getting a second set of eyes and that you will help the reviewer get up to speed. One sentence of confidence beats a paragraph of justification.
2. Give the right access. Read-only access to the repository and documentation is usually enough. Do not hand out production passwords or admin access to live systems for a code review, and do not share anything the client has not approved sharing. [Who owns the code you build for a client](/blog/who-owns-the-code-you-build-for-a-client) is worth rereading if access or ownership is unclear in your agreement.
3. Send a short context document. One page: what the build does, the main decisions you made and why, what was deliberately left out of scope, known limitations, and how to run it. Reviewers judge code harshly when they do not know the constraints it was built under.
4. Ask for findings as a written list. A numbered list, ideally with a severity next to each item, lets you respond point by point instead of reacting to a vague 'there are some concerns.'
5. Offer a call after the findings arrive. A 30-minute call with you, the client, and the reviewer, once you have read the list, settles most disagreements faster than a long email thread.

How to Respond to the Findings

When the list arrives, read it twice before you reply, and sort every item into a bucket. The bucket decides the response, and it stops a review from turning into free rework.

Be honest about the first bucket. If the reviewer found something real, own it in one sentence and fix it. Clients forgive bugs far more easily than they forgive defensiveness. [When a client finds a bug after launch](/blog/client-finds-a-bug-after-launch) covers how to handle the fix itself.

If the review says the code 'looks AI-generated,' do not deny using Claude Code. That is not a finding. The question that matters is whether the code works, is secure, and can be maintained, and that is what your tests, your security review, and your documentation answer. Point to them.

Make Every Build Review-Ready From Day One

The cheapest way to handle a code review is to build as if one is coming. These habits make a review short and boring, which is exactly what you want.

• Keep a project file. A [CLAUDE.md file for client projects](/blog/claude-md-file-for-client-projects) that records the conventions, decisions, and constraints doubles as the reviewer's map of the build.
• Write a readme a stranger can follow. How to run it, how to deploy it, where the settings live, and what is out of scope.
• Run a security review before handoff. [Claude Code's security review for client work](/blog/claude-code-security-review-for-client-work) catches the issues a reviewer looks for first, before they find them.
• Test the important paths. Even a handful of tests on the parts that handle money, logins, or customer data show a reviewer you checked your work. [Browser testing for client work](/blog/claude-code-browser-testing-for-client-work) covers the user-facing side.
• Keep a clean commit history. Small commits with plain messages let a reviewer see how the build came together instead of guessing.
• Offer the review yourself. On your next proposal, mention that the client is welcome to have the code independently reviewed before final payment. Nervous clients relax, and it signals confidence no portfolio can.