How to choose a software development company, and the questions that reveal the truth

Every software company's website says the same four things. Experienced team. Agile process. Quality delivery. Client focused. None of it is false and none of it is useful, because the company that will disappear in week six says it too.

What follows is how to tell them apart. It is written by a studio that gets compared, so read it knowing that, and use it on us as well.

Look at what they refuse to do

A studio that takes every project is a studio with no opinion, and a studio with no opinion will build whatever you ask for, including the wrong thing. Ask what kind of work they turn down. If the answer is nothing, they are selling capacity, not judgement.

The best signal you can get in a first call is being told you do not need the thing you asked for. It costs them the project and it tells you everything.

Ask who writes the code

In a lot of agencies, the person in the sales call is not the person who builds, and the person who builds is not the person you will get in month two. Ask directly: who writes this, and will I talk to them? Then ask what happens if that person leaves.

Small studios win on this and lose on capacity. Large ones win on capacity and lose on continuity. Neither is wrong, but you should know which trade you are making.

Make them show you something unfinished

Polished case studies prove they can design a case study. Ask to see a project mid build, or a weekly build link from a current client with the name removed. The ones who work in the open will shrug and show you. The ones who work behind a curtain will explain why they cannot, and that explanation is the answer.

The scope conversation is the real interview

Watch what happens when you describe your process. A studio that is listening will interrupt with awkward questions: what happens when the approver is on leave, what do you do today when the number is wrong, who checks this. A studio that is selling will nod and start describing features.

You are not buying code. You are buying somebody's understanding of your process, and the quality of their questions is the only evidence of it you will get before you sign.

Eight questions worth asking all of them

• What is not included in this price, specifically?
• What have you built that is closest to this, and what went wrong on it?
• Who owns the code, and whose account is the repository in?
• What do we see at the end of week one, and week two?
• If we change our mind about something in week three, what happens?
• Who do I call six months after launch, and what does that cost?
• What would make you tell us this project is a bad idea?
• What do you need from us, and what happens to the date if we are slow?

The second question is the most revealing and the most avoided. Every real project has something that went wrong. A studio that cannot name one has either not built much or is not going to be honest with you when it happens on yours.

Red flags that are worth walking away from

• A quote arriving without a scoping conversation. They are guessing, and the correction will be your problem.
• A price that is dramatically below everyone else. The money comes back through change requests or it does not come back at all, and neither ends well.
• Unwillingness to put the scope in writing. Everything that is not written down is a disagreement waiting for a deadline.
• The code living in their account, not yours.
• A proposal full of technology names and empty of your process. They are describing themselves, not you.
• No mention at all of what happens after launch.

The last one matters more than the rest

Most software does not fail at launch. It fails eleven months later, when the person who understood it has left, the thing nobody documented breaks, and the studio that built it is busy with somebody else. Ask about month twelve in the first call. The answer tells you whether they are building you an asset or a dependency.