Three things get sold under roughly the same heading, cost wildly different amounts, and answer completely different questions. Buying the wrong one is common and expensive — not because the work is bad, but because it was never going to tell you what you needed to know.
A penetration test
What it is: someone attacks your running system from outside, as an attacker would, and reports what they got through.
What it answers: can this be broken into today, by these methods, in this configuration?
What it cannot answer: whether the design is sound. A pentest sees the outside. If your access rules are wrong in a way that requires a valid login to exploit, a black-box test may never reach it. A clean report means nobody got in during the test window by the routes tried — a genuinely useful thing to know, and narrower than most buyers hear.
Buy it when: you need external assurance, a customer or insurer requires one, or you are about to expose something new to the internet.
A code review
What it is: someone reads the source and reports what is wrong with it.
What it answers: is this code correct, consistent and maintainable? Are there flaws visible in the writing?
What it cannot answer: how it behaves in production. Code review sees intent, not reality — it will not find the misconfigured setting, the permission granted by hand two years ago, or the database rule that was never switched on. The code can be immaculate and the deployment wide open.
Buy it when: you inherited a codebase, you are worried about maintainability, or you want a specific concern investigated properly.
A production audit
What it is: the code, the configuration, the data flows and the operational reality examined together, against the question of what happens when things go wrong.
What it answers: where does this break, who can see data they should not, what fails silently, and what evidence exists that anyone reviewed it?
What it cannot answer: whether a determined attacker gets in — that is the pentest's job, and the two are complements rather than substitutes.
Buy it when: something was built fast, is now carrying real customer data, and nobody has stood back and looked at the whole of it.
Where automated scanning fits
Cheap tiers exist and they are worth what they cost, which is not nothing. A scanner finds what it has a rule for — known vulnerable dependencies, common misconfigurations, credentials in source. That is real coverage, cheaply, continuously.
What no rule engine can tell you is that your multi-tenancy assumption is wrong, that a field nobody flagged is regulated, or that the record you keep will not satisfy the person who asks for it. Those require judgement about your business, and judgement is exactly the thing a pattern matcher cannot supply.
Run the scanner. Do not mistake it for the answer.
Choosing
Ask what question is keeping you up.
"Could someone break in?" — pentest. "Is this code any good?" — code review. "We built this fast and now it holds real customer data; what did we miss?" — production audit.
Most businesses that have shipped quickly with AI assistance are asking the third question, and buying one of the first two, and coming away reassured about something they were not actually worried about.
The Reality Check is the third one, done in a week for a fixed fee — and where the honest answer is that you need a pentest instead, it says so.
This is the part we do — the crossing from a demo to a system that survives production.