How to Evaluate a Software Consultant Before You Sign Anything

The uncomfortable part of hiring a technical consultant is that the thing you're trying to assess is the thing you're hiring for. If you could reliably evaluate the depth of someone's technical judgment, you would probably not need them.

The good news is that the useful signals aren't technical. They're structural, and they show up in the first conversation if you're listening for the right things.

Describe your problem badly and see what happens

The single most useful move in a first conversation is to describe your situation incompletely — which is easy, because you probably can't describe it completely anyway — and pay attention to what the person does next.

Someone who has done this work before will start narrowing. They'll ask which version you're on. They'll ask what else touches the system. They'll ask what happens today when the process fails, and who notices. Within ten minutes they'll be describing a scenario you didn't mention and asking whether it applies, because they've seen your situation somewhere else and are checking whether it's the same shape.

Someone who is good at sales will do something different: they'll reflect your problem back to you in more confident language, and then move toward their process. You'll hear about their discovery phase, their methodology, their team. What separates the two is the direction of the conversation — inward toward the specifics of your system, or outward toward how they work.

The strongest signal in the entire evaluation is a consultant who tells you a part of your problem is harder than you think it is, and can say precisely why. That is very hard to fake, because it requires knowing where the difficulty actually lives. It also runs against a salesperson's interest, which is exactly what makes it informative.

The second strongest is someone who tells you a part of it is easier than you think, or that some of the work you were planning to pay for doesn't need doing.

Notice what they ask you about

There's a category of question that only comes from experience, and it's not the technical ones.

Who else has to approve this. What's driving the date. What happens to this project if the person who sponsored it leaves. Whether anyone has tried this before and what happened. What your team will need to be able to do with the result after handoff.

Those questions come from having watched projects fail for non-technical reasons. A consultant who asks them has been through it. One who only asks about your stack has either not been through it or hasn't learned from it, and the second is worse.

An estimate should have a shape

A number by itself tells you very little. What tells you something is whether the number decomposes.

Ask what the largest single piece of the estimate is, and why. A person who has thought about your project will answer immediately and specifically — the data migration, because the two systems don't share identifiers and reconciliation is most of the work. A number designed to win the work usually can't survive that question, because it was built backward from a budget you signaled rather than forward from the work.

Then ask what would make it take twice as long. The honest answer is always available, because every project has two or three variables that dominate everything else, and someone who understands your project can name them. "We'd need to see the codebase to know" is a fair answer if it comes with what specifically they'd be looking for. "We don't anticipate any issues" is not an answer.

Be wary of estimates with no range and no conditions. Certainty in an initial estimate is not confidence, it's a sales posture — and it usually gets recovered later through change orders.

The first thirty days tell you whether you were right

Whatever the engagement is, structure the beginning so that something real is delivered in the first month. An assessment document. A working slice of the system. A written scope with an actual scope boundary. It doesn't matter much what, as long as it's a deliverable you can evaluate rather than a status report.

You will learn more from that first deliverable than from any amount of reference checking. And structuring the engagement so it exists is worth doing even if you're confident, because the cost of finding out in month one is a fraction of the cost of finding out in month five.

The other thing to watch in that window: whether the person you talked to is the person doing the work. If the engineer who scoped your project has been replaced by a team you haven't met, the evaluation you did no longer applies to the engagement you're in.