Seven questions before choosing a software vendor

Choosing a software vendor is closer to choosing a builder than choosing a product. What decides the outcome is not the feature list in the proposal, but how that vendor works when things do not go to plan.

And things almost always do not go to plan.

The seven questions below need no technical knowledge to judge. You only need to hear the answers and notice what is left unsaid.

How to use this: score your vendor now

If you already have a vendor — or are assessing a candidate — award one point for every question answered clearly, in writing, and without being asked.

The verdict is at the end.

1. What exactly will I receive at the end, in writing?

A good answer names things that can be checked: a working application, technical documentation, user training, and the source code. The words "source code" matter — if they are missing, ask.

A dangerous answer: "a system that fits your needs". That is not a promise, it is a hope. And a hope cannot be invoiced when the project drifts.

2. How are scope changes handled?

Every project changes. What separates a good vendor is not the ability to avoid change, but having a way to record it: what changed, how much extra time, how much extra cost — approved by you before the work is done.

A dangerous answer: "do not worry, small changes are free". It sounds generous. In reality, work that is not costed is also not scheduled — and the thing that runs late is always the thing that was not scheduled.

3. Who owns the code and the data afterwards?

There is only one correct answer: you do.

If the vendor keeps the source code and gives you only access to the application, you are locked in. While the engagement runs, it does not show. The moment you want to leave — because prices rose, because service fell, or because the vendor closed — the exit cost is rebuilding from scratch.

This is the question least asked and most expensive to get wrong. Ask before signing, not after three years.

4. What does it cost after the system is live?

Software does not stop costing money at handover. Servers, security updates, fixes when something breaks, and adjustments when your business rules change.

Ask for a number, not a vague range. "About ten percent of the build cost per year" is an answer. "It depends" is not.

A dangerous answer: not mentioned at all. A proposal showing only the build cost is hiding half of the real cost.

5. May I speak with a previous client?

A vendor confident in their work does not mind. If there is a reason to decline — and there are legitimate ones, such as a confidentiality agreement — ask whether there is another way: screenshots, a written reference, or a client willing to talk without naming the project.

What you need to hear from that client is not praise, but the answer to one question: what was most annoying about working with them?

6. What happens if the system breaks after handover?

A good answer names three concrete things: how long the warranty lasts, how faults are reported, and the expected response time.

A dangerous answer: "we are always available". That is not a commitment, because it cannot be measured. A commitment that cannot be measured cannot be enforced.

7. What can you not do?

This is the most useful of the seven, and the least asked.

A vendor who answers "we can do anything" is not providing information — they are closing the conversation. An honest vendor names their limits: fields that are not their expertise, technology their team has not mastered, or kinds of project that failed before and they will not repeat.

Precisely because that answer works against them, you can trust the rest of what they say.

How to read your score

• Zero to two points — this vendor will cause you trouble. Not possibly, almost certainly. Consider looking elsewhere before the project starts, not after.
• Three to four points — recoverable. Ask for written answers to what is still open, and make them part of the agreement.
• Five points or more — proceed, but get everything into the contract. A good verbal answer can still vanish when staff change.

How we answer all seven

We write our answers to these seven questions into the written summary before a project begins — not because we are asked, but because it is the only way you can assess us fairly.

Deliverables and source code are named up front. Scope changes are recorded with their impact. Annual maintenance is stated alongside the build cost, not after it. Warranty period and response time in writing.

And the seventh: we will name the work you should not give us. We do not take on hardware beyond basic network installation, and we do not accept projects whose deadlines are impossible merely because the budget is large.

The next step

If you are assessing a vendor and the score came out below five, send us the proposal or its summary. We will give an honest opinion on which parts need re-asking — at no charge, and with no obligation to use our services.

If the proposal is already good, we will say it is good. That is not the answer that benefits us today, but a company that lasts is built from clients who never felt deceived.