Business

Nine questions to ask an IT supplier before signing

Assessing an IT supplier without being technical is possible: nine questions on code ownership, continuity, restores, response times and exit terms are enough. Vague answers are already an answer. Ask them before signing, while you still have negotiating power.

15 Mar 2026 · 7 min read · updated on 27 Aug 2026

The hard part, when choosing who will build or run your systems, is not working out whether they are good: it is working it out without being in the trade. Pitches all look alike, quotes are hard to compare, and references are, by definition, the happy ones.

There are, however, nine questions anyone can ask and that are hard to answer well without genuinely having things in order. They need no technical knowledge to ask: they need real practice to answer.

On the ownership of what you pay for

Is the source code ours, by contract? If the answer is "the code stays ours but you have a licence to use it", you are renting, not buying. It is a legitimate choice, but you must know it beforehand and price it accordingly.
If we change supplier tomorrow, what do you hand over and in what time? Code alone is worth little: you need the instructions to rebuild the environment, the credentials, and the data in a format anyone can read.
Which third-party services are essential for it to run? Every external service is a subscription you inherit and a supplier you did not choose.

On depending on individuals

Who besides the person handling us can work on this? In a small firm the honest answer is often "one person": that is fine, as long as it is declared and there is documentation. The problem is not the size, it is pretending not to have one.
How is your work documented? Manuals are not required: what is required is that important decisions are written somewhere other than in someone's memory.

On these two, watch the faces more than the words. People who have worked well answer with examples in ten seconds; people improvising buy time.

Ask before signing. Afterwards, the same question becomes a request — and it comes with a quote.Timing matters as much as the question

On what happens when things go wrong

When was the last backup restored, and who checked the data was complete? This separates those who take copies from those who have a plan. A backup never read back is a file you trust.
How fast do you respond if the system is down, and what happens if you miss it? A time with no consequence is a wish. With a penalty, even a small one, it becomes a commitment.
Who notices first that something is wrong: you or us? If the answer is "you call us", there is no monitoring: there is on-demand support, which costs less and is worth less.
If the server disappears tonight, how long to rebuild it identically? Have you ever tried? The second half of the question is the one that counts.

How to read the answers

Don't look for the perfect answer: look for the specific one. "We take daily backups with thirty-day retention and the last test restore was in February" is a good answer even if the number doesn't please you. "Sure, backups are in place" is not an answer.

Be wary of three things in particular:

The quote that covers everything to the last detail, with firm dates a year out. It means nobody has understood the problem yet, and change requests will follow.
The supplier who asks no questions. Whoever doesn't ask how you work is selling what they already have, not what you need.
Whoever takes offence. These questions are normal between professionals. Treating them as distrust already tells you how they will react when there is a real problem.

The three things to put in writing

Whatever the answers, three things belong in the contract and not in an email thread:

Ownership of code and data, and what is handed over when the relationship ends.
Times for response and recovery, with consequences if they are missed.
Exit: who supports the handover to another supplier, for how long and on what terms.

A serious supplier agrees to write them down, because they know they can meet them. It is in their interest too: a client who knows what to expect argues far less.

If you have a quote open on your desk, print this list and pass it around. At worst you find something out in time; at best the supplier answers well on all nine and you have one more reason to sign.

Isn't it rude to ask all this?

The opposite: people who do this seriously get asked often and have the answers ready. What is rude, if anything, is discovering after two years that the code was never yours.

How many of these should get a positive answer?

Not all of them, and that is normal. A small supplier will have one person on one technology: the point is not perfection, it is that they tell you and that you know how to mitigate it.

Do they apply to whoever only runs our website?

The first three and the last four always do. Even a brochure site holds your content and the enquiries that arrive: knowing where they are and how to take them away is the difference between a supplier and a hostage-taker.

What if we have used the same supplier for years?

Ask anyway, without an accusatory tone: half the time the answers are better than expected, and the other half tells you where to act. A long relationship is not a reason to not know how things stand.