How to evaluate a developer's code quality before you sign a contract

Most companies sign the contract first and look at the code later. That's backwards.

A bad hire is a problem you can fix. You see it, you coach it, you move on. A bad vendor is something else entirely — months of flawed delivery, a codebase nobody can maintain, and a pile of rework that somehow becomes your problem.

And here's the strange part. Almost everyone knows this. Yet almost everyone evaluates contractors the same way: a polished profile, a confident interview, a few good references. None of which tell you the one thing that actually matters. Can this person write code your team can live with?

The honest answer is, you can't know that from a résumé. You have to look at the work.

So that's what this article is about. Not theory. Not interview tricks. A simple, repeatable way to see a developer's real code quality before you commit a single dollar — the methods that work, the red flags that predict trouble, and the contract terms that keep quality from slipping once the work begins.

The best part? You don't need to be an engineer to do any of it.

Why code quality matters even more when you're hiring a vendor, not an employee

Insufficient code quality isn't only irritating but also expensive. Thus, poor software quality cost the US economy an estimated $2.41 trillion in 2022 (CISQ), and developers on average burn about 25% of their time tackling bad code and technical debt issues instead of building.

And while in an in-house team, low code quality can be addressed over time through code reviews, mentoring, and corporate standards, in a distributed setup, this can be a delayed action bomb, as contractors often work more independently and with varied documentation discipline. Consequently, the client inherits whatever was delivered at whatever quality it arrived.

Here are key factors that amplify code quality risk when it comes to a contract engagement:

• Maintainability is your problem, not the contractor's

When the contract ends, your team or another contractor steps in to maintain the code. If this code can be understood by its author only, it isn't an asset but a burden. A contractor who provides something that works today but cannot be safely changed by someone else in, let's say, a year, will bring trouble.

• Documentation gaps multiply problems

In a distributed team, original decision-makers are very rarely accessible. Therefore, undocumented architectural choices often become enduring mysteries that push teams to build workarounds instead of making improvements.

• Tech debt is built up across every iteration

Poor code that a contractor delivered in month one compounds problems for every sprint that follows. What seemed like a small compromise evolves into technical debt that requires substantial effort to repay.

As a result, evaluating code quality becomes much more important when contractors are involved.

The challenge isn't that contractors write worse code than employees but that you usually have fewer opportunities to check and upgrade code quality once the engagement is underway. That's why to mitigate risk, you need to pay particular attention to the initial evaluation and know how to check developer code quality properly.

Definition of code quality for non-coders

Code quality covers a set of traits that together determine whether code is safe to build on, maintain, and hand to someone new.

We can highlight six particularly prominent characteristics, and what is important is that you can reason about all of them without coding yourself.

1. Readability

Good code is read like clear prose with sensible names, logical structure, and no cleverness for its own sake. Any developer who takes a look at the code should be able to tell what it does without calling the person who wrote it.

2. Maintainability

The ease of changing, fixing, or extending code is a key quality indicator. Maintainable code is modular, due to which a change in one place doesn't unexpectedly break something elsewhere in the system. Low maintainability is often the reason a quick fix turns into a two-day investigation, as developers are forced to trace hidden dependencies and unintended side effects.

3. Documentation

A habit of documenting architectural decisions and commenting on non-obvious choices adds to code quality, too. The availability of a README also lets a new engineer set up and run the project. This isn't bureaucracy but a helpful practice that enables distributed and co-located teams to stay efficient and avoid repeated questions or hidden assumptions. DORA research shows there is a clear link between documentation quality and organizational performance.

4. Test coverage

It's always easier to work with code covered with unit tests. The thing is that tests not only ensure the intended system behavior but also enable developers to make changes more confidently. With adequate test coverage, refactoring and feature updates are less risky because unforeseen side effects are detected early. It's also often a sign that a developer cares about long-term maintainability.

5. Security

Security is of high priority across most projects. For this reason, secure code should include proper input validation, safe data handling, secure authentication and authorization flows, and careful management of sensitive information such as tokens or credentials. When these security practices are skipped, costly incidents or emergency fixes show up later.

6. Consistency

The same standards should be applied to the whole codebase. Numerous discrepancies often point to poor discipline or several contributors working without coordination. Whatever the reason, this affects every developer who has to work with the code later.

Together, these characteristics make code quality more evident. Knowing them, you can more objectively assess developers' coding skills.

How to evaluate a developer before signing a contract

Now, as you know what to expect from quality code, we'd like to suggest that you have a look at the most efficient evaluation methods that will let you make the right decision before signing a contract with a vendor or contractor.

Method 1 — Reviewing past work

Reviewing the available code samples is the first thing that usually comes to mind. This pretty simple assessment method can tell you a lot.

You need to request something the developer owns or has permission to share. Ideally, it should be a sample from a completed project in a similar tech stack, but any public GitHub repository, a sanitized internal project, or an open-source contribution would work.

Here are what we'd recommend you look at, even without technical knowledge:

• Structure: Open the repository and check if there is a clear folder layout or if it looks like a pile of files dumped in one place. Structure is visible before you even read a single line.

• Documentation presence: Pay attention to whether a README or a real setup guide is available. Also, scroll through the main file. If there are comments on the non-obvious parts, this tells you that the developer thinks about other people who may contribute to the codebase.

• Commit history: Look at the commit messages. Clear messages like "fix null pointer in auth flow" show discipline, while vague ones like "updates" or "misc" often tell about rushed or unstructured work.

• Test files: If you see a test folder with actual tests in it, it is a good sign. You don't have to read them. Their presence and volume are already a signal.

Be ready for some contractors to have nothing to share. That's a red flag. An experienced contractor usually has at least one project they can show. If they can't do this, ask why.

For a more comprehensive technical assessment of past work, check our guide to technically assessing a developer before hiring.

Method 2 — Using static analysis tools on the provided code

Static analysis tools scan code for complexity, duplication, possible bugs, security weaknesses, and style violations. They can be of great help if you have no one to read the code.

Using them, you can make hiring decisions based not only on a vague feeling that the code looks messy but also on an informative dashboard.

So, how to assess developer code quality using these tools? You just ask a developer to share a sample as a repository, analyze it with SonarCloud or Code Climate, and treat the output as a starting point for conversation. A few warnings on a sophisticated codebase are totally ok, but plenty of critical issues on a simple one are a bad sign.

A few extra tips on interpreting results:

• A maintainability grade of A or B in Code Climate is ok, while a D or F calls for a hard talk.

• Code duplication under 5% is fine. Double digits imply that copy-paste has replaced proper abstraction.

• None of the critical/blocker security issues should be the expectation. One may require an explanation. Several suggest that security hasn't been treated as a priority.

One thing that tools won't catch is whether all tests are useful. For example, a developer may write tests that execute every line but assert nothing real. As a result, the coverage percentage looks great, but the safety net is absent. So, open a few test files and check whether the assertions check behavior or just run the code.

Data provided by static analysis tools doesn't replace judgment, but it helps direct it. This way, you know which questions to ask in the stage that comes next.

Method 3 — A pre-contract code review session

A code review session is usually a 45-to-60-minute call where a developer presents to you and a technical advisor (ideally) their code, explaining decisions, discussing trade-offs, and outlining what they'd do differently having more time. It's the most informative stage in the whole process because it reveals four things at once: code quality, communication, honesty about limits, and behavior under polite scrutiny.

In such a session, developers show not just the ability to produce output but clarity of thought and judgment. To get the full picture, ask about:

• How a module is structured and why it was organized that way

• What they would refactor if given more time

• The consequences of changing parts of the proposed solution

• Which tests were written, and what they actually cover

Strong answers show ownership, recognition of trade-offs, and care for the next person who will maintain the code. Also, it's reassuring when a developer can criticize their own code before someone else does.

On the other hand, it's concerning if a developer can't reason their decisions, get defensive when questioned, or treat tests as an afterthought.

One more piece of advice here: if you aren't a tech person yourself, bring someone who is. For example, a fractional CTO can be engaged for a developer code review pre-contract. The thing is that asking questions is relatively easy, but interpreting the answers correctly requires engineering judgment. Our guide to vetting a senior developer without being a technical expert covers how to borrow that judgment when you don't have it in-house.

Method 4 — A paid small trial task

That's how to evaluate outsourced developer work before they are fully engaged. A scoped trial task is a real but small piece of work completed by a developer before the contract is signed. In fact, this is the best possible simulation of what you will actually receive under contract.

Fair compensation is an important aspect here, as a free coding test shows disrespect for the developer's time. The best candidates often have other options and may simply walk away, leaving you with a weaker candidate pool.

A paid trial task is a professional due diligence step that qualified contractors expect and respect. How should you approach it? Here are a couple of things to consider:

• Keep it tight. All in all, the task should take no more than 4-8 hours of work.

• Make it relevant. The test should be related to the actual project, with clear deliverables and predefined evaluation criteria.

• Score it against the six characteristics. Apply the six code quality traits from the earlier section: readability, maintainability, documentation, test coverage, security, and consistency. In fact, you can use it as a code quality checklist for hiring developers.

• Pay attention to the details. When reviewing the task, look at the code structure, naming standards, comments, and how edge cases are handled. These details tell you more about day-to-day work quality than whether they nailed every requirement.

It is also worth giving the contractor an opportunity to present their work. Set up a 30-minute demo call so that they can walk you through their solution and you can ask your questions.

Red flags in code samples that predict future quality problems

When assessing freelance developer quality, you need to know not only the positive signals but also the warning ones. While the latter may not be enough to disqualify a candidate immediately, it should almost always trigger follow-up questions.

Here is a list of common red flags to watch for:

1. No README or a one-line README

An absence of setup instructions and architecture notes suggests that the developer doesn't think much about handoff, onboarding, and maintainability.

2. Functions or methods that contain hundreds of lines

Very long functions go against the single responsibility principle. If a developer doesn't break down problems into smaller, manageable parts, it's difficult to understand, test, and modify their code.

3. Strange values across code

Numbers such as 17, 365, or 0.85 showing up throughout the code without any explanation confuse the next developer. Even if the author understands their meaning, other developers may not. Important values should be named and documented so their purpose is obvious at a glance.

4. No error handling

Seasoned developers assume that things will occasionally go wrong. If the code doesn't contain checks for failed requests, invalid input, missing data, or unavailable services, that's definitely a warning sign. Without effective error handling, issues that could have been easily addressed turn into crashes or time-consuming debugging.

5. Commented-out code blocks

Commented-out code is old code that should have been deleted. Leaving such dead code in place creates noise and can make you conclude that a developer doesn't clean up after themselves.

6. Inconsistent approach to naming

Using different naming styles in the same codebase makes it difficult to understand how components relate to each other. It may point to careless habits or multiple developers working without shared standards.

7. No test files in the repository

The absence of tests is a warning sign. Without tests, every change is risky because there is no reliable way to verify that existing functionality still works as expected.

8. Vague commit messages

While clear commit descriptions show a structural approach to development and make troubleshooting much easier, messages like "fix," "update," or "changes" that don't explain what was changed and why are a red flag.

If you'd like to spot red flags in conversation, too, our list of developer interview red flags you shouldn't ignore can also be helpful.

What to put in the contract to protect code quality

Arranging a code quality review before hiring a developer is definitely a thing to do. But to make sure quality won't degrade after work begins, development contracts should explicitly define code quality expectations. This way, when disagreements happen, you'll have an objective standard to fall back on.

Here are five points to add to the contract:

1. Coding standards

Specify which coding standards are applied to the project, let's say the Airbnb JavaScript Style Guide, PEP 8 for Python, or whatever fits the stack. It gives both sides an understanding of how code should look and removes ambiguity around style-related expectations.

2. Documentation requirements

Define minimum documentation expectations. This can include a complete README, inline comments for non-obvious logic, and architecture decision records for key design choices.

3. Minimum test coverage

Set a minimum test coverage threshold, for example, 70% line coverage, and specify the testing framework to be used. Without this, there is a possibility of receiving working code with no tests, which significantly increases long-term risk.

4. Code review rights

Reserve the right for your team or an assigned reviewer to inspect the code at a defined milestone before final approval or payment. This allows you to spot quality issues early — not after delivery is complete.

5. Acceptance criteria tied to quality

Define "done" not just as working code, but as code that passes linting rules, meets agreed static analysis thresholds with no critical issues, and is approved by a designated technical reviewer. This makes code quality something concrete rather than just a matter of opinion.

Takeaway

The best pitch doesn't write the best code. It never has.

Think about where contract disappointments actually come from. Not from vendors who looked weak — you'd never hire those. They come from the ones who looked great. The polished deck, the confident answers, the impressive logos. And then the work arrives, and it's nothing like the promise.

There's only one way to close that gap. Look at the code before you sign, and put your expectations in writing once you do.

And don't rely on a single test. One sample tells you almost nothing. A layered process tells you everything — review their past work, run it through static analysis, sit down for a real code review, then pay for a small trial task to see the truth. Each step catches what the last one missed.

That's it. That's the whole idea. It isn't complicated. It's just rarely done.

Or you can skip the legwork entirely. At Devico, every developer's code is reviewed by senior engineers before they ever reach you — so the quality question is answered before you even ask it. Here's exactly how we do it.