How to choose a software development partner: a checklist for business and technical teams

Picking a software partner is rarely a purely technical decision, and it is rarely a purely commercial one either. The person approving the budget and the person who will maintain the system three years from now are usually different people, and they worry about different things. This checklist is written so both can use it, in the same meeting, with the same list.

Short version: choose the partner who asks the most uncomfortable questions before the contract is signed, not the one with the most confident answers.

1. Do they challenge the brief?

A good partner will ask what problem you are really solving, who the users are, and what happens if you do nothing. If a proposal arrives within a day and simply restates your requirements with a price attached, nobody has thought hard about your problem yet.

• Business lens: are you being offered a way to measure success, not just a list of features?
• Technical lens: have they questioned any requirement that looks expensive or risky for little value?

2. Can you see how they work, not just what they have built?

Screenshots of past work tell you little. Ask to walk through how a typical week runs: how work is planned, how progress is shown, how decisions are recorded, and what happens when something slips. You are buying a process as much as an outcome.

3. Who will actually do the work?

Ask for the names and roles of the people on your project, and whether they are employees or subcontractors. Small, senior teams mean you talk to the people writing the code. Large teams can offer more capacity but often add layers between you and the work. Neither is wrong; you just need to know which you are buying.

4. How do they handle uncertainty?

Every project has unknowns. Be wary of fixed prices and dates offered before anyone has explored them. Better partners spend a short, bounded period shaping the work first, naming the risks, deciding what is out of scope, and only then committing to a plan. If you want to understand the trade-offs between pricing models, read our guide to fixed price versus time and materials.

5. What will you own at the end?

This is where business and technical concerns meet. Confirm in writing that you own the source code, the infrastructure definitions, the documentation and the accounts and credentials. You should be able to hand the project to another team without asking permission.

• Code lives in a repository you control from day one
• Infrastructure is defined as code, not clicked together by hand
• Secrets and cloud accounts are held in your name

6. How do they treat quality and operations?

A system that works on launch day and fails quietly in month three is expensive. Ask about automated tests, code review, deployment pipelines, monitoring and what happens when something breaks at 2am. The answers do not need to be elaborate, but they need to exist.

7. Will they say no?

Ask for an example of a time they recommended against something a client wanted, or suggested a cheaper or simpler option. A partner who never says no is optimising for the contract, not for your outcome.

8. What does the relationship look like after launch?

Software is never finished. Clarify who fixes defects, who handles security updates, how changes are requested and priced, and how smoothly responsibility can move to your own team if you choose.

A simple scorecard

Score each partner from 0 to 2 on each of the eight questions: 0 for no answer, 1 for a vague answer, 2 for a specific, evidence-backed answer. Do it separately, then compare notes. Disagreements between the business and technical scores are the most useful part of the exercise.

How we try to answer these

We are a small studio, so you work directly with the people building your system. We begin by shaping the problem before committing to a build, we deliver through automated pipelines you own, and we are happy to be held to every question above. If you would like to test us against this checklist, get in touch.