How to Evaluate a Software Consultant Before You Sign Anything

A non-technical buyer can evaluate a technical consultant reliably, because the useful signals are structural rather than technical. They appear in the first conversation and require no ability to assess the underlying engineering.

The problem the buyer faces is circular: the capability being assessed is the capability being purchased. The four tests below route around that.

Test 1: Describe the problem incompletely and observe the direction

Give an incomplete description of the situation, which is straightforward since a complete one is usually not available, and watch which way the conversation moves.

Toward the specifics of your system. A consultant with relevant experience begins narrowing immediately. Which version. What else touches the system. What happens today when the process fails, and who notices. Within ten minutes they will describe a scenario you did not mention and ask whether it applies, because they have seen the same shape elsewhere and are testing the match.

Toward how they work. A strong sales process reflects the problem back in more confident language and moves to methodology: the discovery phase, the delivery framework, the team structure. The description of your problem gets better without getting more specific.

The direction of that first ten minutes is the most reliable early signal available.

Test 2: Listen for the assessment that costs them

The strongest single indicator is a consultant who states that part of the problem is harder than you believe and can say precisely why.

This is difficult to fabricate, because it requires knowing where the difficulty is located. It also runs against the immediate sales interest, which is what makes it informative.

The second strongest indicator is the same move in the other direction: a consultant who tells you that part of the work is easier than expected, or that something you planned to pay for does not need doing. Both signals come from the same source: an actual model of the work rather than a model of the sale.

Test 3: Note which questions they ask you

A category of question comes only from having watched projects fail for reasons that were not technical.

• Who else has to approve this
• What is driving the date
• What happens to this project if its sponsor leaves the organization
• Whether anyone has attempted this before, and what happened
• What your team needs to be able to do with the result after handover
• Who decides scope questions, and how quickly

A consultant asking these has been through the failure modes. One who asks only about the technology stack has either not encountered them or has not drawn conclusions from them, and the second case is the worse one.

Test 4: Require the estimate to decompose

A number by itself carries almost no information. Whether it breaks apart under questioning carries a great deal.

Ask what the largest single component of the estimate is, and why. Someone who has thought about your project answers immediately and specifically: the data migration, because the two systems share no common identifier and reconciliation is the majority of the work. A number constructed backward from a budget signal cannot survive this question, because it was never assembled from parts.

Ask what would double the timeline. An honest answer is always available. Every project has two or three variables that dominate the rest, and someone who understands the project can name them. "We would need to see the codebase to know" is a legitimate answer when it comes with a statement of what specifically they would look for. "We do not anticipate any issues" is not an answer.

Treat certainty as a warning. An initial estimate with no range and no stated conditions reflects a sales posture rather than confidence. The variance is recovered later through change orders.

Structure the first thirty days to produce a verdict

Whatever the engagement, structure the opening so that something evaluable is delivered within the first month.

Acceptable first deliverables:

• A written assessment of the existing system
• A working slice of the product, deployed somewhere you can use it
• A written scope with an explicit boundary stating what is excluded

The form matters less than the property: it must be a deliverable you can evaluate, not a status report describing progress toward one.

That first deliverable will tell you more than any reference check. Structuring the engagement to produce it is worth doing even when you are confident, because the cost of learning you were wrong in month one is a fraction of the cost of learning it in month five.

Verify the engagement matches the evaluation

Watch, in that same window, whether the person you evaluated is the person doing the work.

If the engineer who scoped the project has been replaced by a team you have not met, the evaluation you performed no longer applies to the engagement you are in, and none of the signals above were about the people now doing the work. That substitution is worth addressing contractually before it happens rather than after.