What to ask before you hire anybody to build software

Software projects fail in predictable ways, and most of them are visible in the first conversation if you know what to listen for.

## "What happens if this takes longer than you think?"

You are not asking for a promise. You are finding out whether they have thought about it. An honest answer describes what happens: who absorbs the cost, how you would be told, what gets cut.

Be wary of "that will not happen". It will.

## "What do you need from me, and when?"

Projects are late because of content, decisions and access far more often than because of code. Somebody who has finished projects knows this and will have a list. Somebody who says "nothing, just leave it with us" has not, and you will discover the list halfway through.

## "Who owns the code when it is finished?"

You should. Get it in writing.

The answer to watch for is ownership contingent on an ongoing arrangement: that you own it as long as you stay on their hosting or their support contract. That is not ownership.

## "What happens if I want to move to somebody else?"

Ask it directly, and watch the reaction as much as the answer. A confident supplier will tell you what you would get and how the handover works. An uncomfortable one is telling you something.

## "Can I see something you built that is still running?"

Not screenshots. A live thing, being used by somebody. If everything they can show you is either confidential or no longer online, that is worth a pause.

## "What is not included?"

Better than asking what is included, because the list of inclusions is where the enthusiasm is and the list of exclusions is where the arguments come from. Hosting, domain, content, training, support, changes after launch. Get each one named as in or out.

## "What does support mean, exactly?"

"We will support it" means nothing. How quickly do they respond? Is it included or billed? Does it cover changes or only faults? Through which channel?

A clear answer here is the single best sign that the supplier has done this before.

## "How will I know how it is going?"

Ask how often you will see working software, not reports about software. A short demonstration every week or two, of something you can click on, tells you more than any progress percentage. It also means a misunderstanding is found while it costs a day to fix rather than a month.

Agree who your single point of contact is, and how quickly they answer. A project where you have to chase for news is usually a project that is behind.

## "How will we test it before it goes live?"

Somebody other than the person who built it should use it before your customers do, and that somebody is often you. Ask for time set aside to try the finished work with real examples from your business: a real invoice, a real customer, a real awkward case. Ask what happens to the problems you find, and whether fixing them is included in the price.

Ask as well how a change is made after launch, and how long it takes. Software that works on day one but cannot be changed safely six months later is a problem you have simply postponed.

## On price

The cheapest quote is often the one that has understood the job least, and the gap gets made up in changes later. Look at what each quote actually covers before comparing the numbers; frequently they are not quoting the same work.

And be wary of a fixed price given before anybody has asked what the software has to do. It is either padded heavily or about to become a negotiation.