Twelve questions to ask a software vendor before you sign 

Before signing with a software vendor, ask who owns the code and the accounts, where the system will run, who supports it after go-live, how scope changes are priced, whether they earn commissions on tools they recommend and what happens if you want to leave. A good vendor answers all of these in writing without hesitation.

Why the questions matter more than the quote

Two quotes for the same project can differ by a large margin and the cheaper one isn't always the worse one. In my opinion what decides whether the project works for you is not the price but the terms behind it. That means who holds the code, who answers the phone after launch and what it costs you to change your mind.

I've kept the questions below short on purpose. I'd email them to each vendor and compare the written replies side by side, because a vendor who answers clearly is showing you how they'll work with you later.

The twelve questions

1. Who owns the code and the accounts?

If you don't own them then you can't move to another team. A good answer is that the finished work belongs to you and the code sits in a repository under your account. Hosting, domain and other accounts should be opened in your name with the vendor invited as a user.

2. Where does it run, and who pays for it?

Hosting is a running cost and a point of control - whoever holds the account holds the keys. Look for a named hosting provider, the expected monthly cost, the account in your name and a plain description of where your data is stored.

3. Who supports it after go-live?

Many builds fail quietly once the team moves on to the next client. You want a named contact, a reply time you can write into the agreement and a clear description of what is covered and what costs extra.

4. Do you take vendor commissions or referral fees?

A vendor paid by a tool supplier may recommend that tool for the wrong reason. What you want here is a direct yes or no. If it's a yes then they should tell you which tools and how much in writing, and if it's a no then they should say so plainly.

5. What happens when scope changes?

Scope change is the usual cause of delay and disputes. A good answer is that every change gets written down, sized and approved by you before work starts, with its effect on time and cost shown to you up front.

6. Who will actually do the work?

The people in the sales meeting may not be the people who build your system. I'd ask for the names or roles of the people on your project, how many of them are involved and whether any work is passed on to another company.

7. How will I see progress?

Weeks of silence usually hide trouble. You want regular demos of working software, a shared list of what is done and what is next, and a named person you can reach whenever you need to.

8. How do you handle security and my data?

You are trusting them with your customer and business records, so this one matters a lot. A good answer explains how sign-in and access are controlled, how backups are made and tested, who can see your data and how they'll handle a problem if one happens.

9. What do you need from us, and how fast?

Projects slow down when the business is slow to decide. Look for a clear list of what the vendor needs from you, like one decision maker, sample data and some review time each week.

10. What is out of scope?

What gets left out causes the biggest surprises, which is why I'd always ask this one. You want a written list of what the first release won't include so nothing you assumed is quietly missing.

11. What do I receive if the project stops?

Projects stop for all sorts of reasons. A good answer is the code, the data, the documentation and access to every account, delivered to you in a usable form and with no fee for the handover beyond what the contract states.

12. What happens if I want to leave later?

You should never feel locked in to one vendor. Look for short notice terms in writing, no charge to export your data and a written guide that another team can use to take over from them.

Red flags

• A vendor who won't say who owns the code until you pay.
• Accounts and hosting opened in the vendor's name with no handover plan at all.
• A price for a whole platform when your problem is one specific gap.
• Pressure to sign this week when there's no written scope.
• No clear named person who will support you after launch.
• Vague answers to question 4, 11 or 12 on the list above.
• No demos of working software until the end of the project.
• A flat refusal to put any of these answers in the contract.

One red flag may have an innocent explanation, so ask about it before you judge. Several of them together are a good reason to look elsewhere, and if you ask me you shouldn't feel bad about walking away.

How should you use the answers?

Put the answers into a simple table with one row per question and one column per vendor, then mark each answer as clear, vague or missing. The pattern usually shows up quickly. Then ask the vendor you prefer to put the key answers into the contract so they're binding and not just promises made in a meeting. Hope this helps, and good luck with the shortlist!

Frequently asked

Here are a few short answers to the questions that tend to come up next.