Eight Questions to Ask a Software Vendor Before You Sign

Most companies choose a software vendor by comparing proposals. The proposals all look similar, because they are written by people whose job is to make them look similar, so the decision comes down to price and whoever presented most confidently.

That process tests sales capability. It does not test delivery capability, and those are different skills that frequently live in different people. Knowing how to choose a software vendor means asking questions whose answers are hard to fake.

Here are eight we would ask. The useful part is not the question itself; it is what a good answer sounds like, and which answers should end the conversation.

1. Who specifically will work on this, and what else are they on?

Why it works: Proposals are written with senior names attached. Delivery often happens with whoever is free. This question surfaces the gap.

A good answer names individuals, states their allocation as a percentage, and admits that some of them are finishing something else. A bad answer talks about "our team" and "bench strength" without naming anyone.

2. What happened on your last project that went badly?

Why it works: Every supplier with real delivery history has one. The question is whether they will tell you about it.

A good answer describes a specific failure, what caused it, and what changed afterwards. A bad answer is a humblebrag about a client who was too ambitious, or a claim that nothing has gone wrong. The second is either untrue or means they have not done much.

3. What would make you tell us this project is a bad idea?

Why it works: A supplier who cannot describe circumstances in which they would decline work will accept work they should decline. Yours might be it.

A good answer is concrete: unclear ownership, no internal technical counterpart, a deadline that cannot move. A bad answer is that they can make anything work.

4. How do we get our system back if we stop working with you?

Why it works: This is the question that most changes the balance of a relationship, and almost nobody asks it during selection.

A good answer covers repository ownership, credentials, documentation and a realistic handover period, and is offered without defensiveness. A bad answer treats the question as a sign of bad faith. You are asking about an exit precisely because you intend to stay, and a supplier who understands that is one worth staying with.

5. Who owns the code, and where is that written down?

Why it works: The answer is usually "you, obviously" and is usually less obvious in the contract.

A good answer points at a specific clause. Watch for third-party components under restrictive licences and for any proprietary framework of the vendor’s own, which can make the code technically yours and practically unusable without them. A bad answer is a reassurance with no document behind it.

6. What do you need from us, and what happens if you do not get it?

Why it works: Projects fail on the client side at least as often as the vendor side, usually because nobody said out loud what the client had to provide.

A good answer lists specifics: decisions within a stated time, access to named systems, a person with authority to resolve disputes. A bad answer is that they will handle everything. They will not, and the bill for that discovery arrives later.

7. How will you tell us when something is going wrong?

Why it works: Every project hits trouble. The difference between a recoverable problem and a crisis is how long it stays hidden.

A good answer describes a mechanism: a regular written status with a real risk section, a named escalation path, a standing commitment to raise slippage in the week it happens. A bad answer is "we are very communicative".

8. What compliance obligations does this system create for us?

Why it works: For a European SME, a new system frequently drags in obligations the buyer did not price. Where personal data, AI components or critical infrastructure are involved, the regulatory surface is larger than the technical one.

A good answer distinguishes what the vendor handles from what remains yours, and names the specific regimes. A bad answer treats compliance as somebody else’s department. Our compliance readiness work with Materna exists because that division of responsibility is routinely left undefined until an audit forces the question.

The pattern behind all eight

Every question above tests the same underlying thing: whether the supplier will tell you something you would rather not hear, before you are committed rather than after.

A vendor who answers all eight candidly, including the uncomfortable ones, is showing you how they will behave when the project is late. That is worth considerably more than a lower day rate, and it is the only part of a selection process that reliably predicts the outcome.

If a supplier’s answers get vaguer as the questions get harder, that is your answer.

Frequently asked questions

Should I run a formal tender or approach suppliers directly?

For most SME projects, a formal tender adds paperwork without improving the decision, because it rewards proposal-writing over delivery. Talking to three suppliers properly, with the questions above, tends to produce a better outcome than a scored matrix filled in by people who will not be doing the work.

How much should I share before signing an NDA?

Enough for the supplier to tell you the project is a bad idea. Suppliers who cannot assess feasibility without full commercial disclosure are rarely the problem; buyers who withhold so much that nobody can give an honest assessment usually are.

What if the best answers come from the most expensive vendor?

That is common, and it is not automatically a reason to pay the premium. Ask what the cheaper supplier would have to be right about for their price to hold. If the answer depends on nothing going wrong, you are not comparing like with like.

If you want someone in the room who has asked these questions before, book a 30-minute technical audit conversation.