How to choose a software development partner

Guides on how to choose a software development company typically tell you to check portfolios, read testimonials and compare quotes. All three are close to useless. Portfolios show the successes, testimonials are collected from the happy end of the distribution, and quotes measure how confidently someone will guess at a number.

Here is what actually predicts a good outcome.

Ask what they turned down

The single most informative question: what work have you declined recently, and why?

An agency with judgement has a real answer, usually with mild regret attached — a project that was underfunded for its ambition, a client who wanted something they could have bought off the shelf, a technology bet they thought was wrong. An agency with only capacity to sell will struggle, because the honest answer is "nothing".

You are hiring judgement. This question tests it directly, and it is hard to prepare for.

Find out who is actually writing the code

The most common way agency engagements go wrong has nothing to do with technical skill. You are sold by senior people and delivered to by whoever is available.

Ask directly:

• Who specifically will work on this? Can I speak to them before signing?
• Are they employed by you or subcontracted?
• What else are they working on during this period?
• What happens if they leave mid-engagement?

Reasonable answers exist for all of these. What matters is that they are answered specifically rather than deflected into reassurance about "the team".

Ask to see a handover, not a demo

Anyone can demo a working application. Ask instead to see a repository they handed to a client — and, if the client agrees, to speak to the engineer who inherited it.

That conversation tells you everything: whether the tests were real, whether the documentation was written as they went or hastily assembled at the end, whether the team could be productive in a week or spent a month reverse-engineering.

Handover quality is the part of the work that is invisible while you are buying and expensive forever afterwards.

The questions that surface risk

"What would make this project fail?" Anyone who says nothing has not thought about it. A good answer names two or three specific risks, unprompted, including ones that are your fault rather than theirs.

"What's the cheapest version of this that would still be useful?" You are testing whether they will help you spend less. Note that this is against their immediate interest, which is exactly why the answer is informative.

"How do you handle scope changes?" You want a process — a written change with a price attached, decided explicitly. Both "we're flexible" and "the contract is the contract" are wrong answers.

"What are you not good at?" Specific limitations are a strong signal. "We're generalists" is not an answer.

A vetting scorecard you can actually use

The questions above are the qualitative core of vetting a software agency, but a structured scorecard makes it easier to compare several candidates consistently rather than relying on impressions that fade between conversations held days apart. Score each candidate from zero to two on each dimension — zero for a poor or evasive answer, one for an adequate one, two for a genuinely strong one — and total the result.

A candidate scoring twelve or above out of a possible fourteen is worth a paid scoping engagement. A candidate scoring under eight has usually failed on judgement or transparency specifically, which are the two dimensions least likely to improve once money is committed — a supplier evasive about the delivery team during evaluation does not typically become forthcoming after the contract is signed.

This is not meant to replace judgement with arithmetic — a candidate who scores adequately everywhere but exceptionally on judgement and risk awareness is often a better bet than one who scores well everywhere but shows no distinctive strength. The scorecard's value is in forcing the same questions to be asked of every candidate, consistently, rather than letting the most polished pitch set the bar for what counts as a good answer.

A software procurement process that does not take three months

For anyone running this as a software procurement process rather than an informal search, a structured sequence keeps it from either dragging on indefinitely or collapsing into picking whoever pitched most recently.

Week one: identify three to five candidates. Referrals from people who have actually used the supplier are worth more than any marketing material — ask specifically whether the referrer would hire them again, not just whether the project succeeded, since a project can succeed despite a difficult supplier relationship.

Week two: structured conversations with each, using the same question set. The consistency matters more than the specific questions chosen — comparing candidates fairly requires asking each one the same things, not letting the conversation wander differently with each.

Week three: request scoping proposals from the top two or three. Ask each for a short, paid proposal — not a free pitch — for how they would approach discovery on your actual project. This surfaces real thinking rather than generic capability statements, and paying for it, even a modest amount, filters out suppliers who are not genuinely interested.

Week four: commission one paid scoping engagement. Not a contract for the full project — the scoping phase specifically, structured so its output is useful even if you take it elsewhere afterward, as covered above.

Week five onward: decide based on the scoping engagement itself, not the pitch that preceded it. How they actually worked together with your team for two weeks is a far better predictor of the full engagement than any conversation, however well-structured.

This whole process runs in about a month for most mid-sized engagements, and it consistently outperforms the alternative of an extended, unstructured search that stretches to three months and still ends in a decision made mostly on gut feel.

Structure the engagement to limit damage

However good the evaluation, you are still guessing until you have worked together. So make being wrong cheap.

A paid scoping engagement is the highest-value thing you can buy from a prospective partner. You get a specification and an architecture — useful regardless of who builds it — and you find out how they work before the money gets serious.

Be wary of anyone who wants to skip straight to a six-month contract, and of anyone who offers to do the scoping free. Free scoping is sales, and it is priced accordingly: the output is optimistic.

Settle ownership in writing

Before anything starts:

• Code in your repository, your licence, from the first commit
• Infrastructure in your cloud accounts, not theirs
• Domains, DNS and third-party accounts registered to you
• Anything proprietary they intend to use, named explicitly, with the terms for leaving

The failure mode is not malice. It is default arrangements that were convenient at the start and become leverage at the end. A partner who has done this before will have clear answers ready.

Agency red flags

The agency red flags worth watching for, gathered in one place:

• A quote produced without asking substantive questions
• Estimates with no range and no stated assumptions
• Reluctance to name the engineers
• A proprietary platform you would have to keep paying for
• Enthusiastic agreement with every idea you float
• Pressure to sign before a small engagement can be run
• No opinion about what to cut

None of these are individually fatal. Two or three together usually are.

What happens after the contract, not just before it

Vetting well before signing solves most of the risk, but not all of it — a few things are worth establishing explicitly once an engagement is under way, because they are hard to retrofit if skipped at the start.

Agree the communication cadence in writing, not by assumption. Weekly demos of deployed work, not weekly status calls describing work in progress. The distinction matters enormously — a status call can describe anything, while a demo of something actually running cannot be faked, and it is the single best early-warning system for a project drifting off track.

Establish who on your side is actually reviewing the work as it lands, not just receiving periodic updates. Even a technically limited founder benefits from having someone — internal, or an independent technical advisor — looking at what is being built as it is built, rather than discovering problems only at a milestone review when changing course is more expensive.

Revisit the relationship at each milestone boundary, explicitly. Not as a formality — as a genuine checkpoint where either side can flag that something is not working and adjust, which is exactly the value of the milestone structure covered in fixed price versus time and materials. A partner uncomfortable with this kind of regular, explicit check-in is telling you something about how they expect the relationship to run.

How this connects to the pricing and hiring decisions around it

Choosing a partner does not happen in isolation — it sits alongside two other decisions covered elsewhere. Whether hiring in-house makes more sense than any external partner at all is covered in hiring versus outsourcing engineering, and worth revisiting before starting a search if the honest answer might be that the work belongs inside the company. And whichever partner is chosen, the specification format that determines whether a fixed price is trustworthy is the same one covered in how we scope a build — a strong partner will insist on exactly this kind of scoping before quoting, which is itself one more signal worth adding to the evaluation above.

What to expect from a good one

They will narrow your scope. They will raise problems early, when it is awkward. They will be specific about what they do not know. They will hand you something your own team can own, and they will not be needed afterwards.

That last point is worth dwelling on. A partner whose commercial model depends on you being unable to leave will make decisions accordingly, and you will not notice which ones until much later.

The evaluation never really stops

Vetting does not end once a contract is signed — it continues, in a lower-key form, for as long as the relationship runs. The same qualities worth checking for during selection — judgement, transparency, willingness to say no — are worth watching for throughout the engagement, because a partner can pass every check during evaluation and still drift once the relationship feels settled. Treating the first milestone as an extension of the vetting process, not a separate phase that begins once evaluation ends, is what keeps a good initial choice from quietly becoming a mediocre ongoing one.

Trust, verified continuously

The relationship between a client and a development partner works best when trust is extended incrementally and verified continuously, rather than granted wholesale after a good pitch or withheld entirely until a track record exists. Each milestone delivered well earns a bit more latitude on the next; each surprise, however small, is worth raising immediately rather than filing away. This is simply good management applied to an external relationship, and it is the practical version of everything covered in this piece once the paperwork is signed and the actual work begins.

A practical next step

Before contacting any agency, write the five questions from this piece on a single page and commit to asking every candidate exactly the same five, in the same order, before discussing price at all. Score the answers immediately after each conversation while they are fresh, using the scorecard above if that helps. This structure alone — asking the same things of everyone, in the same order, scored consistently — removes most of the bias that lets the most polished pitch win regardless of the substance behind it.

What experience teaches

Founders who have been through this process more than once tend to converge on the same lesson, regardless of industry or product: the evaluation conversation itself, done properly, is more predictive than any reference call or portfolio review, because it is the one moment where you can watch how a prospective partner actually thinks under a real, specific question rather than a rehearsed pitch. Everything in this piece is really in service of engineering that one conversation to be as revealing as possible, as early as possible, before any money is at stake.

One more thing worth saying

A good partner makes this entire process easier, not harder — they will volunteer the information this piece tells you to ask for, before you have to ask. That willingness is itself the clearest signal available.

The clients who get this right

The clients who consistently find good partners are not the ones with the sharpest negotiating tactics — they are the ones who ask the same handful of specific, hard-to-fake questions of every candidate, every time, and take the answers seriously.

Last word

The best partner you will find is not the most polished one — it is the most honest one, and honesty is testable before you sign anything.