How to Choose a Software Development Partner

Most people choose a development firm badly, and not because they are careless. They run the process in an order that makes a good decision impossible: approach several firms with a loose description, collect wildly different numbers, and then pick using the only dimension that is actually comparable, which is price.

This is about running it in a better order. A separate post covers the warning signs that a firm will not finish — worth reading alongside, because that one is about individual firms and this one is about the process.

Start by writing down what you want, badly

Not a specification. You do not have one yet, and if you had one you would not need this.

A page. What is going wrong today, who it affects, what you have already tried, which systems are involved, and any date that matters. Written in your own words, describing the process rather than the software you think you need.

This page does two jobs. It gives every firm the same starting point, which is the only way their responses will be comparable. And the quality of what comes back is itself the first filter: a firm that responds with questions about your process is thinking; a firm that responds with a proposal has stopped listening.

Three firms, not seven

Seven feels thorough. It is not. It is a fortnight of calls, seven documents in seven formats, and a decision made on whoever was most recently persuasive.

Three is enough to see a range. Pick them deliberately: ideally one that has worked in your sector, one that has solved your shape of problem elsewhere, and one that somebody you trust has actually used. If two of the three tell you the same uncomfortable thing about your project, that thing is true.

Make the quotes comparable, or do not bother comparing them

This is where almost every selection goes wrong.

A $15,000 quote and a $60,000 quote for "the same project" are not usually a judgement about value. They are quotes for different projects. One has assumed the integration is out of scope. One has assumed you will supply the designs. One has read the same page you sent and priced the version they think you actually need.

You have two honest options.

Pay for the scoping, from one firm. A discovery engagement produces a written specification — screens, rules, edge cases, what is explicitly out of scope. You keep it whether or not you continue with them, and you can hand it to the other two. Now the quotes are comparable because all three are pricing the same document. This costs money up front and it is by a distance the most reliable way to run this.

Or force a like-for-like breakdown. Ask every firm for the same structure: a list of screens, the integrations included, who supplies design, what testing is included, what happens after launch, and a dated out-of-scope list. If a firm will not produce that, you have learned something.

What does not work is comparing three totals. The lowest number is very often the firm that understood the least, and you pay the difference later as change requests.

What to actually check in a portfolio

Screenshots prove nothing. Anyone can produce a screenshot.

Something running that you can open. A live URL beats everything. Use it. Click into the parts that would be hard — the search, the filtering, the thing that would need real data behind it.

Code you can look at, or somebody who can. If you have a technical person, ask for a repository or a representative sample. You are not auditing it. You are looking for tests, for readable structure, for commit history that looks like a team rather than one heroic weekend.

A written account of one hard decision. This is the best signal available and almost nobody asks for it. Ask a firm to explain the hardest technical decision on a recent project and what they would do differently. A firm that has genuinely operated software has a real answer and usually a slightly painful one. A firm that has not will describe a feature instead.

Who actually did it. The work in a portfolio was done by specific people. Ask whether those people are still there and whether they would be on yours.

The questions worth asking

Six, and what you are listening for.

Who writes the code, and can I meet them this week? Vagueness here is the strongest predictor of a bad engagement. If the people who scope it are not the people who build it, context gets lost at the handover and you pay for the gap in rework.

What happens when you underestimate? Under fixed price the answer should be "that is our problem". Watch how fast it comes.

When do I see working software, and how often after that? Weekly or fortnightly is healthy. "At the end of each phase" means you find out too late to steer. A demo should be something you click, not a slide with a percentage on it.

What is explicitly not included? A firm that has thought about your project can list four or five things immediately. A firm that says "we will handle everything" has not read your page.

Who owns the code, and from when? The answer should be you, from the first commit, in a repository in your own organisation. Not handed over at the end.

What happens if we want to stop? For a project: what you keep. For a retainer: the notice period and what handover includes. Ask before you sign, when it is a hypothetical and the answer is honest.

Structure the money to match the risk

The pattern that protects you is simple: payments land after deliverables, not before them.

A large deposit before anything exists removes the pressure that keeps a project moving. Milestone payments tied to things you can actually inspect — the signed specification, the first working demo, feature-complete, live — keep both sides pointed the same way. Retainers are different and monthly in advance is normal there, because you are buying capacity rather than an outcome.

Be wary of hourly for a defined build. Hourly means the party doing the estimating benefits from having estimated badly, which is a structural problem rather than a question of anyone's honesty. We wrote out the full argument in fixed price versus hourly.

The three contract terms that matter

Most of a development agreement is boilerplate you will never invoke. Three clauses are worth reading properly.

Ownership and when it transfers. You want the code, the repository and the infrastructure accounts, with transfer at creation rather than at final payment. The version where ownership transfers on completion gives a firm leverage at exactly the moment you are most exposed.

The change process. Changes should be re-quoted in writing and approved before work starts. The mechanism matters more than the rate. What you are avoiding is the conversation where work you did not authorise appears on a final invoice.

Exit. Notice period, what handover includes, and whether documentation and training are deliverables or favours. A firm that has written a clean exit into the agreement is not planning to leave. It is telling you it does not need to trap you.

The thing nobody tells you

The best possible outcome of a selection process is sometimes that a firm talks you out of the project.

Buying existing software. Fixing the process before automating it. Hiring somebody permanent instead. Any firm willing to say one of those is giving up revenue to tell you the truth, and that is information about how they will behave in month three when something is going wrong and it would be easier not to mention it.

If all three of your firms enthusiastically agree with everything you said, you did not test them hard enough.

---

Want to run this on us? Ask us every question above. If the answers do not satisfy you, that is useful information either way.