How to choose a software company without being a technical person

You are about to spend a significant amount on something you cannot evaluate directly. That is uncomfortable, and the usual response — asking about technologies — makes it worse, because the answers are unverifiable.

You do not need to assess technical skill. You need to assess whether someone understood your problem, and whether they will still be reachable in a year. Both are assessable without technical knowledge.

The signal that matters most

Do they ask more questions than they answer?

A supplier who responds to your first description with a quote has not understood the problem, because your first description was not complete — nobody's is. A good one will spend the first conversation asking about your process, your existing systems, who will use it, and what happens when things go wrong.

The strongest signal is a supplier who, twenty minutes in, restates your problem back to you more clearly than you stated it. That is the whole test, and it works regardless of your technical background.

Seven questions, and what the answers mean

"Can you show me something similar you have built, and tell me what went wrong with it?"

Everyone has a portfolio. What you are listening for is the second half. Every real project has a difficult part; a supplier who cannot name one either has not delivered much or is not being straight with you.

"Who exactly will do the work?"

You want names and a reason to believe those people will still be on it. Beware the senior team at the pitch and a different team afterwards.

"Who will own the code?"

The answer must be you, without qualification. Hesitation here is the single most useful red flag on this list — see nine things to check in a contract.

"What happens after launch?"

Ask specifically: who fixes defects, for how long, at what cost, and how fast. A supplier without a clear answer has not thought past invoicing.

"What do you need from us?"

Good suppliers are demanding. They need decisions, access, and someone's time. A supplier who says "nothing, leave it with us" is describing a project that will deliver something you did not want.

"What would you not build for us?"

A supplier willing to say "you do not need this, buy it instead" is worth more than one who agrees with everything. If everything you suggest is a good idea, you are talking to a sales process, not an engineer.

"Can we start with something small and paid?"

The single best risk reducer available. Two to four weeks, tightly scoped, with a real deliverable. It costs a fraction of the project and tells you more than any reference list.

Warning signs

Checking references properly

Ask for three, and ask for one where things went wrong. A supplier who cannot provide that either has no history or is managing your impression.

When you speak to a reference, avoid "were you happy?" — nobody says no. Ask instead:

• What surprised you about the project?
• What did you have to do that you had not expected?
• If you did it again, what would you change?
• Are they still responsive now?

That last one matters most. Plenty of suppliers deliver well and vanish afterwards.

What price actually tells you

Little, on its own. A large spread between quotes usually means the brief allowed several interpretations, not that one supplier is dishonest.

Normalise before comparing: same scope, same handover, same warranty, same maintenance assumption, over three years.

The genuinely cheapest quote is worth one question: what is missing? Usually it is the admin interface, error handling, or any support after launch.

Common questions

Big company or small team?

A small team gives you the people you met and faster decisions. A larger firm gives you continuity if someone leaves. For most projects under six months, the small team wins on outcome; above that, ask directly what happens if your lead developer goes.

Local or remote?

Time zone matters more than distance. A supplier one or two hours from you shares a working day; eight hours away means a day's delay on every question. The considerations are in nearshoring to Egypt.

Should we write a specification first?

Write one page, not a specification. Who uses it, the three things they do, which systems it must talk to. A supplier who cannot work from that page — or who will not help you turn it into a scope — is not the right supplier.