Skip to content

Choosing a software supplier: eight questions for the first meeting

6 min read
Digital Transformation
Choosing a software supplier: eight questions for the first meeting

Key Takeaways

  • 1The first meeting shows how a supplier thinks about your problem, not only what it can build
  • 2Ask about scope, data ownership, support, exit and change handling before any contract is drafted
  • 3A vague answer is information, so write down what was said and compare suppliers on the same questions
  • 4Vague or evasive answers about data and exit are the strongest warning signs
  • 5Send the same eight questions to every supplier and score the answers together with a colleague

Most disagreements with a software supplier start with something nobody asked about at the beginning. Who owns the data? What happens when we want to change something in month four? What if we want to move on? These are easy questions to ask and awkward to ask late.

This article is for a managing director or head of operations who is about to meet one or more suppliers. It gives eight questions for the first meeting and says what a weak answer usually means. It is about choosing before you sign, not about leaving a product you already use.

How to use the questions

Send the list to every supplier a few days ahead, and ask the same people to answer in the meeting. Take notes in a shared sheet with one row per question and one column per supplier. Bring a colleague who will not be involved in the project day to day; they ask the naive questions that matter.

Do not look for perfect answers. Look for answers that are specific, that admit limits, and that are the same when you ask again in a different way.

1. What exactly will be delivered, and what will not?

Ask the supplier to describe the result in your words: who will use it, which tasks it will cover, and which related tasks stay out. Good answers name things that are out of scope without being pushed.

A weak answer is "everything you need". It means the boundary will be argued later, usually at your cost.

2. Who owns the data and the code?

Ask who owns the data you put in, who owns the software built for you, and what licence applies to any parts the supplier reuses from other projects. Ask for the answer in writing before the contract stage.

A weak answer is "we will sort that out in the contract" with no position stated. The position should be clear at the first meeting, even if the wording comes later.

3. Who will actually do the work?

Ask who will be on your project, how many of them are employees, and what happens if one of them leaves. Ask to meet the person who will lead the delivery, not only the person who sells.

A weak answer is a team that is only described by role, or a lead who changes after signing.

4. How do you handle a change after we start?

Every project changes. Ask how a change is requested, who estimates it, how fast you get an answer, and whether you can say no after seeing the estimate. Also ask what happens to the plan when a change is accepted.

A weak answer is "we are flexible". Flexibility with no process means a surprise on the invoice or a delay nobody announced.

5. What happens after the first release?

Ask who fixes defects, how fast they respond, who is reachable outside the project, and what is included in support compared with what is paid separately. Ask for a description of a typical month of support for a similar customer, without names.

A weak answer is that support is "available" with no response times or contact route. Support is a service with an owner, not a promise.

6. How will we see progress before the end?

Ask what you will be able to see and try every two to four weeks, and who on your side has to be available to give feedback. Working software shown regularly is better evidence than a status report.

A weak answer is a long period with nothing to see, followed by a large delivery.

7. What do you need from us?

Good suppliers know that delays often come from the customer side: access, decisions, people's time, test data. Ask what they will need and when, and what happens to the schedule if it arrives late.

A weak answer is "nothing special". It suggests the supplier has not thought about how your organisation works, or will blame you later.

8. How would we leave if it did not work out?

Ask how you would get your data out, in what format, how long it takes, and what happens to the running system and the documentation. Ask what you would need to hand the work to another supplier. Ask this calmly and early; a confident supplier answers it easily.

A weak answer is annoyance, or a long explanation of why you will not need it. The exit route is part of the product you are buying.

Comparing the answers

After the meetings, sit down with your colleague and mark each answer as clear, partly clear or vague. Do not add the marks into a single score; look at the questions that matter most for your situation. For most companies those are data ownership, change handling and exit. A supplier with one weak answer and a willingness to put it in writing is often a better choice than one who sounds smooth on all eight.

Then ask each supplier to follow up in writing on the vague points. How quickly and how precisely they respond is the last piece of evidence before the contract stage.

A short checklist

  • Send the eight questions to every supplier before the meeting
  • Bring a colleague who is not part of the daily project
  • Record answers in one shared sheet, one column per supplier
  • Mark each answer clear, partly clear or vague
  • Ask for written follow-up on every vague point
  • Do not move to a contract until data ownership and exit are clear in writing

If you are still deciding what to ask for, see how to write a one-page brief for a custom software project before asking for quotes. For the contract form, see fixed price or time and materials: choosing a software contract by stage. If you are buying AI agents, questions to ask an AI agent vendor before signing covers the specific points for that case.

Sources

  • Our related articles linked above.
  • The approach described is a general working practice, not a standard; adapt it to your organisation. No figures or client results are claimed in this article.

Share this article

Need expert guidance?

Let's discuss how our experience can help solve your biggest challenges.