Questions to ask a software supplier

Put the same questions to every supplier you are considering, and write down what each one says. Ask for the answers that matter most to you in writing.

Where a question touches the contract, copyright or data protection, take advice before you sign. Nothing here is legal advice.

The people who will do the work

1. Who will do the work, and can we meet them before we sign?

   Good: you meet the people who will write the software, as well as the person selling it.

2. Are they your employees, contractors or another company?

   Worrying: the supplier is vague about who it passes work to, or where they are.

3. Who is our day-to-day contact, and who covers when they are away?

   Good: one named contact and a named deputy.

4. What happens to our system if a key person leaves you?

   Good: more than one person knows it, and what they know is written down.

Ownership and access

5. Who owns the source code once we have paid? The source code is the set of files the software is built from.

   Good: you do, and the contract says so. Take advice on the wording.

6. Where is the code kept, and is that account in our name?

   Good: a repository (the store that holds the code and its history) owned by your organisation, with the supplier given access.

7. Whose name are the hosting, domain and third-party accounts in?

   Worrying: anything registered to the supplier or to one of its staff.

8. Does the software rely on anything you own and would keep if we left?

   Good: each such component is listed, with the terms for using it afterwards.

9. What documentation will we hold, and when is it updated?

   Good: build and release instructions, kept current as part of the work.

Price and scope

10. Is the price fixed or charged by time?

    Good: either, stated clearly, with what would cause the figure to change.

11. What is in the scope, and what is not?

    Worrying: a one-line description and a total, with no list of exclusions.

12. How are changes priced and approved?

    Good: each change is quoted and agreed in writing before work starts.

13. When do we pay, and what do we receive at each payment?

    Good: payments tied to something you can see working.

14. Which costs are not in your quote?

    Good: hosting, licences and third-party fees are estimated at the start.

How the work is done

15. How will we see progress?

    Good: working software shown at regular intervals, not only status reports.

16. How is the software tested before it reaches us?

    Good: a described process, with automated tests for the parts that matter most.

17. How does a change reach the live system, and how is it undone?

    Good: written release steps that include a way back.

18. Who decides that a piece of work is finished?

    Good: you do, against acceptance checks agreed in advance.

19. How is our data handled during development?

    Good: test data or anonymised copies, and a short list of people who can see live data.

After launch

20. What happens to faults found after go-live?

    Good: a stated period in which faults in the delivered work are fixed without charge.

21. What does ongoing support cover, and during which hours?

    Worrying: either side assuming that support means cover around the clock.

22. How quickly do you respond to an urgent fault, and is that in the agreement?

    Good: written response times, with a definition of urgent.

23. Who applies security updates and checks the backups?

    Good: a named responsibility, and a restore that is tested from time to time.

24. How will we hear that something the system depends on is nearing the end of vendor support?

    Good: the dates are tracked and raised with you well before they pass.

Leaving

25. What notice do we give to end the contract?

    Good: a notice period you could act on, with any exit charges stated.

26. What will you hand over, and in what state?

    Good: code, data, credentials and documentation that another team could pick up.

27. Will you help a new supplier take over, and at what rate?

    Good: paid handover time at a stated rate.

References and evidence

28. Can we speak to two clients with a system like ours?

    Good: yes, directly, without the supplier on the call.

29. Can we see an example of a report, a specification or a handover pack?

    Good: a real or sample document that shows the level of detail you would receive.

30. Tell us about a project that went badly and what you changed afterwards.

    Worrying: a supplier that says nothing has ever gone wrong.

Compare the suppliers

Score each heading from 1 (vague or worrying answers) to 5 (clear answers, confirmed in writing). A low score under ownership or leaving deserves more weight than a high score elsewhere, because those are the hardest things to put right after you have signed.

If you are moving away from an existing supplier, the supplier transition plan sets out the handover phase by phase.