Ten questions to ask a software vendor before signing.

Hiring someone to build software is uncomfortable because you're buying something that doesn't exist yet, without knowing enough to judge it. These ten questions even out that playing field quite a bit.

You don't need to know anything about technology to ask them. And in most cases, what matters isn't the answer, it's whether the other person had one ready.

1. What happens if I ask for a change halfway through?

You're looking for a procedure to exist. "We'll figure it out" is a bad sign. "I'll quote it separately and you decide if it's worth it" is a good one.

2. What's explicitly excluded?

A quote that only lists what's included is incomplete. Ask them to write down what isn't, and you'll avoid the "I thought this was part of it" conversation, which is where relationships break down.

3. Whose name are the accounts and the code under?

Everything should be in your name: the services you're paying for, the domains, the code. If something is registered under the vendor's name, the day the relationship ends you have a serious problem.

It's an uncomfortable question to ask and a perfectly normal one to answer.

4. What do you need from me, and by when?

A vendor who doesn't ask you for anything hasn't understood the project. They're going to need decisions, data, and someone available. If they don't mention it now, they'll demand it later, once the delay is on you.

5. How often will I see something working?

The answer should be measured in weeks, not months. If you only see the system at the very end, you have no way to correct course while correcting it is still cheap.

6. What happens after it's finished?

Every system needs maintenance: laws change, the services it depends on change, bugs show up. Ask what's included after delivery, for how long, and what it costs once that period ends.

7. Who else could maintain this if you're not around?

Nobody who works cleanly takes offense at this question. What you're looking for is a system built with well-known tools and documented enough that someone else could pick it up.

If the answer suggests only that one person can touch it, take note.

8. How is my customers' data handled?

Where it's stored, who can see it, what happens if something goes wrong. Even if your company is small, your customers' data is your responsibility, not the vendor's.

9. What's a similar project you've done, and can I talk to that client?

A five-minute call with a past client is worth more than any presentation. And if they can't give you a single reference, that's a data point in itself.

10. What's most likely to go wrong here?

The best of the ten questions, and the one asked least often.

Someone who knows the craft will name two or three concrete risks specific to your project. Someone who says they don't see any risks either has no experience or isn't going to tell you. Neither is good.

How to read the answers as a whole

Don't look for perfect answers. Look for answers that exist, that are specific to your case, and that include some kind of limit.

A vendor who tells you everything is possible, it'll be fast, and they don't see any problems isn't putting you at ease: they're telling you they haven't actually thought about your project yet.

Bring this list printed to the meeting. You'll notice the difference between quotes before you even look at the numbers.