How to choose a software development company, and what to ask before you do

Choosing a software development company is a decision made on incomplete information, usually by someone who will not be the one working with them daily, against proposals that have been written to look alike. The standard comparison points make it worse. Price is negotiable, portfolios are curated, and headcount tells you about the company rather than about your project.

What predicts whether a build goes well is narrower than that, and it is knowable in advance if you ask directly.

Before you speak to anyone

Write down what you are buying and how you will score it. Not a requirements document: a page.

Three things belong on it. The problem, stated as what is wrong today and what would be different if it were fixed. The constraints that are real, meaning a date that comes from outside, a budget that is actually approved, a system that cannot be replaced. And your scoring criteria with weights, agreed with whoever else is in the decision.

Doing this after you have met vendors does not work. Once you have seen three proposals, your criteria quietly reshape themselves around the one you liked, and the vendor who presents best wins regardless of who would deliver best.

The five questions

1. Who exactly works on this?

Names, roles, and what share of their week you get. Then: are these the same people I have been talking to?

The gap between the pitch team and the delivery team is the most common disappointment in this industry, and it is rarely a lie. It is a structural habit: firms put their strongest people in front of prospects because that is what wins work. The fix is simple and few buyers use it. Ask for the names in the contract, with a clause that says substitutions need your agreement.

Then ask what happens if one of those people leaves. A firm with a real answer has thought about handover. A firm that looks uncomfortable is telling you about its key-person risk.

2. What happens when a requirement changes?

Every build changes. What varies is whether the vendor has a process or an attitude.

A good answer has a shape: the change is written down, the vendor states the effort and schedule impact within a few working days, and you approve or decline it. Better answers include swaps, where a new item replaces an unstarted item of similar size at no charge.

A poor answer is “we are flexible”. Flexibility with no mechanism means the conversation happens later, under pressure, when somebody has already done the work.

3. What do I own at the end?

Source code, repository access, infrastructure accounts, the documentation, and the right to hand all of it to somebody else.

Ask to see the clause. Ask before scope and price are discussed, because a clause you raise at the end looks like a negotiating tactic, and a clause you raise at the start is simply diligence. If a vendor hosts the application on their own accounts, ask exactly what leaving looks like and how long it takes.

This costs nothing to establish up front, and it is close to impossible to fix after eighteen months of work sits inside somebody else’s infrastructure.

4. What would you tell me not to build?

The question that separates a partner from a supplier.

Every brief contains something that should not be built: a feature that serves one loud stakeholder, an integration that costs more than the problem, a report nobody will open. A vendor who has read your brief properly has spotted at least one. A vendor who says the whole thing sounds great has either not read it or is not going to argue with you about anything, which becomes expensive later.

Ask for a specific example from a previous client, and what they proposed instead.

5. When would I hear that a date is at risk?

You are testing the reporting culture, and there is a good proxy for it: working software, weekly, that you can use yourself. A vendor who shows you a running system every week cannot hide a slipping date for long. A vendor who reports progress as percentages can hide it for months.

Comparing quotes that look nothing alike

Wildly different numbers almost always mean the vendors are quoting different things. Normalize before comparing:

1. The same feature list, at the same level of detail.
2. Integrations named, with who supplies credentials and test environments.
3. A shared definition of done, covering tests, documentation and acceptance.
4. Who does user testing, who writes acceptance criteria, and who signs off.
5. What the estimate assumes, written down by each vendor.

Most of the spread disappears here. What remains is usually seniority mix and contingency, and both are legitimate differences you can now actually discuss.

The reference call worth making

Ask for a client whose project was difficult, not a showcase. Then ask three questions: what went wrong, how did you find out, and how long was it between the vendor knowing and you knowing.

Everything goes wrong somewhere. You are not testing for a perfect record, which does not exist. You are testing whether problems traveled toward you or away from you.

Score it, then decide

Rank each finalist against the criteria you wrote before the first call. Where a score is low, write the sentence that made you mark it down. That sentence is what you take into the final conversation, and it is usually the thing that turns a close call into an obvious one.

If it would help to have the scoring sheet rather than build one, the free resource bundle includes a vendor scorecard, an RFP template and a build-versus-buy worksheet, none of which name a supplier or require anything from you. They are the documents we would want a client to use on us.

And if you would rather start from where your own operation actually stands, the readiness assessment is twenty questions about how the work runs today. It produces a scored report and a phased plan, which is a more useful thing to hand a shortlist than a requirements document written from scratch.