How to Choose a Software Development Partner

Selecting a development partner is one of the higher-variance decisions a technology leader makes. The same brief, given to two competent-looking firms, routinely produces one engagement that ships on time and one that quietly consumes two quarters and ends in a rebuild. What is uncomfortable is how little the standard selection process does to distinguish between them.

Most RFP scoring rubrics measure things that are easy to compare and weakly predictive: years in business, headcount, logo wall, a portfolio of screenshots, and a day rate. None of those tell you whether the team will notice that your data model cannot support the feature you asked for.

Here is what does.

Ask what they would tell you not to build

This is the single most informative question in a first conversation, and the response separates firms faster than anything else on your evaluation sheet.

A partner who is invested in your outcome has opinions about scope. They will tell you the reporting module you have specified is going to cost more than it returns, that the mobile app you want is better served by a responsive web application for the first year, or that the integration you have described has a dependency nobody has validated. A vendor optimising for contract value will find every part of your brief exciting.

You are not looking for contrarianism. You are looking for evidence that they have thought about your problem rather than about your budget.

Insist on meeting the people who will do the work

The gap between the pre-sales team and the delivery team is where a substantial share of disappointing engagements begin. You are shown a principal engineer with fifteen years of relevant experience; you are staffed with two juniors and a delivery manager who translates between you.

Ask directly: who specifically will be on this project, what else are they working on, and can I speak with them before we sign? Any hesitation here is information. Firms that staff honestly are happy to answer, because their answer is a selling point.

Follow up on continuity. Rotation destroys context, and context is most of what you are paying for after the first month. Ask what their average engineer tenure is and how often people move between accounts.

Understand how they handle being wrong

Every project encounters an estimate that was optimistic, a requirement that was misunderstood, or an architectural decision that turned out badly. What matters is not whether this happens but what happens next.

Useful questions:

• Tell me about a project that went badly. What did you do?
• When you discover an estimate was wrong, when do we find out?
• Who absorbs the cost of an estimating error on fixed-scope work?

The last question is worth asking plainly. On genuinely fixed-scope work, an estimating error is the vendor's risk — that is what fixed scope means. A firm that cannot answer clearly is describing time and materials with a fixed-price label on it.

Look at how they talk about their previous clients

Pay attention to what happens when a partner discusses past work. Do they describe outcomes with numbers, or adjectives? Do they mention things they got wrong? Do they credit the client's team, or present themselves as having rescued a helpless organisation?

The last one is a genuine signal. A firm that describes every previous client as chaotic and every prior vendor as incompetent will eventually describe you the same way to someone else — and more practically, it suggests a working style that does not collaborate well with an internal team.

Five things that should end the conversation

Some signals are strong enough to be disqualifying on their own.

They quote a fixed price before discovery. A precise number against a two-page brief is not confidence; it is either padding large enough to absorb the unknown or a figure that will be revised through change requests. Both are worse for you than a paid discovery phase with an honest range.

They will not put code in your repository. Some firms keep the code in their own organisation until final payment, or use a proprietary framework you would need to license. Both create leverage over you that has nothing to do with the quality of the work. Code should land in your repository from the first commit.

They have no opinion on testing. Ask what their testing approach is. "We test thoroughly" is not an answer. You want to hear about levels — what gets a unit test, what gets an integration test, what genuinely needs a browser — and about how tests run in CI. A firm without a considered position here will hand you a suite that nobody trusts.

Everyone is senior. A firm where every engineer is described as senior is either mis-titling people or has no way to develop talent. Mixed teams are normal and healthy; opacity about composition is not.

They agree with everything. If nothing in your brief has prompted a question or a challenge across several conversations, they are not engaging with the problem. That will not change after you sign.

Structure the first engagement to be cheap to exit

Whatever the outcome of your evaluation, structure the first commitment so that being wrong is survivable.

A paid discovery phase of one to four weeks is the best mechanism available. It is small enough that the decision is low-risk, long enough to see how the team actually works, and it produces something you own regardless of what you do next — a domain model, a technical approach, a costed backlog. If you do not proceed, you take that document to the next firm and your second evaluation is dramatically better informed.

Watch these things during discovery:

• Do they ask questions that make you think, or only questions that fill in a template?
• Does the written output show they listened, or is it a restatement of your brief?
• When they disagree with something you said, how do they raise it?
• Is the estimate accompanied by stated assumptions and a confidence level?

That last one matters more than the number. An estimate without assumptions is a wish. An estimate that says "we are assuming the payment provider's sandbox is representative, and if it is not this grows by three weeks" is a professional artefact.

The uncomfortable summary

The firms that deliver well are usually the ones that made the sales process slightly harder — the ones that pushed back on scope, insisted on a paid discovery phase, declined to give a number before they understood the problem, and were direct about what they could not do.

That is genuinely counterintuitive when you are under pressure to choose quickly and cheaply. But the cost of choosing badly is not the fee. It is the two quarters, the team's confidence, and the fact that you now have to run the selection process again with less budget and less patience.

---

If you are running an evaluation and want a second opinion on a technical approach or an estimate you have received, we are happy to look at it — including when the answer is that the other firm's proposal is the better one.