Before you pay anyone to review software, get straight answers to seven questions. A good reviewer will be happy to answer them. If you get vague answers to more than one, keep looking.
1. Who actually does the work?
Some firms sell with a senior name and staff the job with someone junior. Ask who will read the code, and whether that's the same person you're speaking to now.
When I do a review, I run the application and its tests myself. That's the standard I'd hold anyone else to as well.
2. What access do you need, and on what terms?
A proper review needs read access to the code and enough context to run it. It shouldn't need write access, production passwords or your customers' data.
Ask how access is granted, how it's removed, and whether they'll sign your confidentiality agreement. On mine, access can be revoked the moment the engagement ends, and I'll review and sign your NDA.
3. What will I receive at the end?
Ask to see what a report looks like, or at least a description of it. Look for a written report with findings ranked by how serious they are, and a plain-English summary you can hand to a board or investor without translating.
Most important is whether it gives you an answer. Something that lists 140 findings and stops there leaves you where you started. You want a position: carry on, fix some things first, or start again.
4. Is it a fixed fee?
Ask what the price covers, and what would change it. A fixed fee for a defined scope means you know the cost before it starts and the reviewer has no incentive to find problems just to fill time. Check what's in scope: how many repositories, how much code, how many integrations.
5. Are they independent of whoever built it?
This is the question people forget. If the reviewer works for the supplier, resells the supplier's services or hopes to win the remediation work, their opinion has a commercial pull. That doesn't make them dishonest, but you can't tell from outside whether it's shaping the report.
Ask directly: do you have any relationship with the team that built this, and would you take on the fix work? An honest reviewer who also offers follow-on work will say so and explain how they keep the two apart.
6. What happens if the result is bad?
You're commissioning the review because something might be wrong, so plan for that. Ask what the process is when the findings are serious. Will there be a walkthrough call where you can ask questions? Can the findings be shared with your supplier? Is there a way to check that the critical items were fixed?
Also ask about the opposite case. If the code is in good shape, will they tell you plainly? A reviewer whose fee depends on finding problems has a reason to find some.
7. Can they stay on afterwards?
Some reviews end in a report and a handshake. That's fine if you have a technical team who can act on it. If you don't, the report can sit in a drawer, because nobody is able to turn it into work.
Ask whether the reviewer can help beyond the report: prioritising the fixes, briefing a developer, or acting as your technical lead for a few days a week until you've hired someone. Fractional technical leadership is a separate service I offer, so it's worth asking any reviewer whether they can do the same.
Two further checks
Ask what they won't be able to tell you. A reviewer who says the report covers everything is overselling. Real limits exist: a review looks at what it's given, at a point in time, and it can't predict how your users will behave.
And ask for the scope in writing before the work starts. It protects both sides.
Where to start
If you're about to go live with a build someone else delivered, or you've inherited a system you can't judge, the code and architecture review is a fixed-fee review that ends in a written answer. If you want to check whether it fits first, send me a few lines about what you have and I'll tell you honestly.