You can't read the code, but you can absolutely run a code quality audit, because the health of a codebase shows up in behavior long before it shows up in the diff. How fast can a new developer ship something. How nervous does the team get before a release. How many people actually understand how the system works. Every one of these is a question you can ask in a 30-minute meeting, no technical background required.
I've been on both sides of this, as the CTO answering these questions and, more usefully for you, as the outside reviewer brought in to answer them about someone else's system. The proxy signals are consistent enough that you don't need to trust anyone's self-report. You just need to ask the right questions and notice when the answers don't add up.
The one question that tells you the most
"How long does it take a new developer to ship their first small change?"
In a healthy codebase, this is days, maybe two weeks for something more complex. In an unhealthy one, it's a month or more, and the excuse is usually some version of "our system is just complicated." Complexity is real, but a month to ship anything is a documentation and structure problem, not an intelligence problem. It means new people can't find their way around, which means the current team is the only group that can safely touch the code, which is a business risk you're carrying without knowing it.
Ask this question of your vendor or your internal lead directly. Then ask it again of the most recently hired developer, separately. The gap between the two answers is informative on its own.
Signals you can check without opening an editor
- Deploy frequency and mood. Ask "when did you last deploy, and was it stressful?" Teams with healthy code deploy often (daily or weekly) and treat it as routine. Teams with fragile code deploy rarely and treat every release like a small emergency. If deploys happen monthly and everyone tenses up beforehand, that's your answer.
- The bus factor question. "If [senior developer] took a month off tomorrow, what would happen to the roadmap?" A good answer names two or three people who could cover. A bad answer is a long pause, or a single name repeated back to you nervously.
- Bug recurrence. "Do we see the same category of bug come back after it's been fixed?" Recurring bugs in the same area usually mean the underlying code, not just the symptom, was never actually addressed.
- Documentation reality check. Ask to see the onboarding doc a new hire gets. Not for technical accuracy, just check if it exists, and ask the most recent hire if it was actually useful or if they learned everything by asking around.
- Test coverage as reported, then reality. Ask what percentage of the code has automated tests. Any number, then ask "when a test fails, does the team stop and fix it, or comment it out and move on?" The second answer matters more than the first.
Reading the answers like a McKinsey case, not a tech quiz
None of these questions require you to understand a single line of code, but they do require you to notice inconsistency. If your vendor says deploys are smooth but your account manager mentions "we had a rough weekend getting the last release out," that's a flag. If the team says documentation is solid but the newest hire says they were lost for three weeks, that's a flag. You're not grading technical skill, you're checking whether the story matches the experience of the people actually living it.
This is the same audit logic I'd apply to a build versus buy decision: the real risk usually isn't visible in the pitch, it's visible in how the team behaves under normal operating conditions.
When to bring in an outside reviewer
Run the above yourself first, it costs you nothing but time. Bring in an external technical reviewer when any of these show up:
| Signal | Why it matters |
|---|---|
| One person holds all the critical knowledge | Single point of failure for your entire business |
| Onboarding takes over a month | Structural problem, not a training problem |
| The team resists letting anyone look at the code | Usually a sign they already know it wouldn't hold up |
| You're about to acquire, invest in, or heavily rely on this system | The cost of being wrong here is much larger than the audit fee |
A real audit at that point runs a day to a few days of a senior engineer's time, usually in the range of 8 to 20 million Rupiah depending on system size, and it should produce a plain-language report, not a stack trace. Ask for exactly that up front, so you're not handed forty pages you can't use.
The takeaway
A code quality audit doesn't require you to read a single function. It requires you to ask about onboarding time, deploy confidence, bug recurrence, and who holds the knowledge, and then to actually listen for the gap between what you're told and what the newest, least invested person on the team experiences. Run that conversation quarterly with any vendor or internal team you depend on, and bring in outside technical eyes only when the answers genuinely don't add up. If you want a second opinion on a system you're about to bet the business on, that's exactly the kind of engagement ervandra.com takes on.