How to spot a good software vendor (and the red flags)

You spot a good software vendor before they build anything: by whether they ask first, whether they talk about risks, and whether they tell you what is not worth doing. Portfolio and technology come second.

Choosing a vendor is hard precisely because you only see the quality of the work after months, once the money and time are already spent. But there are signals you can read in advance.

Good signs before you sign

The strongest signal is that they ask "why". A vendor who wants to understand your problem before proposing a solution is unlikely to sell you something pointless. Anyone who knows exactly what to build at the first meeting either was not listening or is recycling a past project.

The second good sign is that they talk about risks. "This might be harder than it looks" is not weakness, it is experience. Anyone promising it will all go smoothly either has not done this long enough or is not telling you the truth.

The third is a willingness to say no. A vendor who occasionally talks you out of what you want is thinking about the outcome, not the invoice. We write about it in where not to use AI — sometimes the best advice is "do not do this".

Red flags

Be careful when:

• A price arrives with no questions. An exact figure for a project nobody has understood yet is guessing dressed up as certainty.
• Everything is "no problem". Real development has trade-offs. Anyone who does not mention them either cannot see them or is hiding them from you.
• They cannot explain what they do. If you leave the answers more confused than before, that is not your fault. A good vendor can make complex things simple.
• Code ownership is vague. It must be in writing that the result is yours and can be handed to somebody else. Without that, you are trapped.
• They will not discuss what happens after handover. Software has to be maintained. Anyone pretending the project ends at launch is not preparing you for reality.

Questions worth asking

Ask what happens if the brief changes mid-project — the answer tells you how they approach a partnership. Ask who will maintain the code and who owns it. And ask about a project that did not work out and what they learned from it. Anyone without such a story either has not done enough or is not being honest.

How the engagement model affects the risk on your side is covered in fixed price or hourly.

The takeaway

You do not spot a good vendor by how nicely they talk about technology, but by how they approach your problem. We built our whole way of working on the idea that context comes before code — and we are happy to show it in practice in a free consultation.