How to Tell If an External Developer Is Doing Good Work When You Cannot Read Code

Hiring well does not solve the problem for good. You can evaluate external developer candidates carefully, pick someone with a strong portfolio and a clean first demo, and still end up six months later with no idea whether the work is holding up. The usual advice covers what to check before you sign the contract: deliverables, questions, access. This is the version for after that, the ongoing read you can do every month without opening a single file.

The four checks below do not require technical knowledge. They require pattern recognition over a few months, which is a skill any manager already has from watching other parts of the business. You are looking for the same kind of drift you would notice in a sales pipeline or a customer support queue: is this getting better, staying flat, or quietly getting worse.

Four ways to evaluate external developer work without opening a single file

Each of these checks uses something you already receive: release notes, incident write-ups, status reports, and the dates work was promised against the dates it actually shipped. None of them need technical training to read. They need you to look at the trend over months instead of judging any single update on its own.

Release frequency tells you more than release speed

Ask how often changes actually reach production, not how often the team says it is "almost ready." A healthy external team ships small, frequent changes, often weekly or more. A team that is struggling tends to batch everything into large, infrequent releases because each one is risky and nobody wants to do it twice.

Track the gap between releases over three or four months. If it is shrinking, the team is getting more confident in its own process. If it is growing, or if releases keep getting delayed by a week "to be safe," that is the codebase telling you something the developer may not be saying out loud: it has become harder to change without breaking.

You do not need release notes written for engineers. Ask for a one-line log: date, what changed, who it affects. If that log has gaps of a month or more with no explanation, ask why. A good answer names a specific blocker. A vague answer is the thing to worry about, not the gap itself.

Count incidents, then read how they get explained

Every system has incidents eventually. What separates a developer doing good work from one who is not is not the incident count alone. It is whether the same kind of incident keeps happening, and what the explanation sounds like after the third one.

Ask for a short note after anything that breaks in production: what happened, how long it took users to notice, how long it took to fix, and what will stop it from happening the same way again. Keep these notes somewhere you can scroll back through. After a few months, read them together instead of one at a time.

If the "what will stop it from happening again" line keeps changing between incidents, that is a developer learning. If it keeps repeating the same vague phrase, something like "we'll monitor it more closely," across unrelated incidents, that is a developer who has not actually found the cause and is hoping it does not come up again. This is one of the clearest non-technical signals available, and it works regardless of what the system is built in.

Clarity in reports beats confidence in reports

A monthly or biweekly report is where the real evaluation happens, and the thing to watch for is not whether the report sounds confident. Confidence is cheap and easy to fake in writing. Clarity is harder to fake, because it requires the writer to actually understand what they are describing.

A clear report names specific things: which feature shipped, which bug affected which users, which dependency got updated and why it mattered. A report that leans on general statements, "progress continues to be strong" or "the team remains focused on quality," without a single specific example, usually means there is nothing specific good to report, or the person writing it does not fully understand the state of the project.

Pay particular attention to how risk gets described. A developer doing good work will tell you about a risk before it becomes a problem: a library nearing its end of support, a part of the system nobody has touched in a year, a dependency on a third-party service that has been flaky. A developer who only reports risk after it has already caused an incident either is not looking for it or does not want to be the one who brings it up. Neither is a good sign, and both are visible from the reports alone.

Watch how estimates hold up, not whether any single one is right

A single wrong estimate means nothing. Estimating software work is genuinely hard, and even experienced developers get individual tasks wrong by a wide margin. What matters is the pattern across several estimates over a few months, which you can track with nothing more than a spreadsheet and the dates things were promised and delivered.

Look for two patterns specifically. The first is a developer whose estimates are consistently, predictably off in one direction, say twice as long as promised, every time. That is not bad luck. That is either overconfidence that never gets corrected or a reluctance to give you a number they think you will not like. The second is a developer whose estimates swing wildly, sometimes early, sometimes months late, with no apparent reason. That usually points to a codebase where nobody, including the person working in it, can tell how hard a change will be until they are already inside it.

A developer who is learning your system will narrow the gap over time. One who keeps missing estimates the same way, or by increasing margins, is either not learning the system or not being honest with you about what they are finding. Either way, you will see it in the numbers you already have, without reading a line of code.

When the signals point the wrong way

If more than one of these four checks is trending badly at the same time, releases slowing, the same incident explanations repeating, reports getting vaguer, estimates drifting further off, it is worth bringing in someone to look at the actual state of the codebase before the relationship gets worse. That does not have to mean replacing the developer. Often it means an outside code quality review that tells you, in plain terms, what is actually wrong under the surface and whether it is a people problem, a process problem, or a codebase that has quietly become harder to work in than anyone has said out loud.

This is the kind of assessment we do for founders and non-technical owners who can see the symptoms above but cannot tell what is causing them. It does not require you to understand the code either. You get a written answer: what state the system is actually in, what it will cost to fix, and what to do next.

If any of the four patterns above sound familiar, get in touch at hello@wolf-tech.io or have a look at what we do at wolf-tech.io. An outside look at the actual codebase often answers in a week what months of reports could not.