Choosing a software development partner: a checklist for UK businesses

Before you talk to anyone

Agencies can only give useful answers if you can describe the problem. Half a page is enough:

• What happens today, step by step, and who does it.
• What goes wrong: the time it takes, the errors, the things customers complain about.
• Which tools are involved, such as spreadsheets, accounts, CRM or e-commerce.
• What a good result looks like in six months.
• A rough budget range and any hard deadline.

You do not need a full specification. A good partner will help you turn this into one, and how they do that tells you a lot about them.

Questions to ask, and what good answers sound like

1. “What would you build first, and what would you leave out?”

Good answer: a small first release that solves the most painful part of the problem, plus a clear list of what is deliberately not included. Warning sign: agreeing to build everything at once, or a proposal that simply repeats your wish list back to you.

2. “How do you price, and what happens if the scope changes?”

Good answer: a fixed price for a clearly defined scope, or a transparent time-and-materials rate with a budget cap, and a simple written process for changes. Warning sign: a single number with no breakdown, or vague answers about how changes are charged.

3. “How will I see progress?”

Good answer: working software you can click through every one or two weeks, on a link you can open yourself. Warning sign: status reports and slide decks, with the first working version promised for the end of the project.

4. “Who will actually do the work?”

Good answer: named people, where they are based, and whether you can speak to them directly. Warning sign: senior people in the sales meeting, then unnamed subcontractors you never meet.

5. “Who owns the code, the data and the accounts?”

Good answer: you do. Intellectual property is assigned to you on payment, the code lives in a repository you control, and hosting is in an account in your name. Warning sign: the agency keeps the code, licenses it to you, or hosts everything in its own accounts.

6. “What happens after launch?”

Good answer: a defined warranty period for fixing defects, an optional support arrangement with clear response times, and documentation good enough for another team to take over. Warning sign: no mention of support until after you sign.

7. “Can you tell me about something similar you have built?”

Good answer: a specific example, ideally something you can see, and an offer to put you in touch with a client. Warning sign: only logos and statistics with no detail behind them.

8. “Should we build this at all?”

Good answer: an honest view, including when an off-the-shelf product would do the job. A partner who never says no is selling hours, not advice.

Warning signs during the sales process

• A detailed quote after one short call, without questions about how the work happens today.
• Pressure to sign quickly, or large discounts for signing this week.
• No written proposal, or a proposal with no list of exclusions.
• Reluctance to name the people who will work on the project.
• Testimonials and case studies you cannot verify.

What to put in the contract

• Scope and exclusions for the first release, with acceptance criteria.
• Payment linked to milestones you can see working, not to calendar dates.
• Intellectual property assigned to you on payment, including design files.
• Access to the code repository and hosting accounts throughout, not just at handover.
• Data protection: a data processing agreement if the agency will handle personal data, as required by UK GDPR.
• Warranty and support: how long defects are fixed free of charge, and the terms of any ongoing support.
• Exit: what the agency hands over if either side ends the relationship.

Comparing proposals

Put proposals side by side on the same scope. The cheapest is rarely the best value; look at what is excluded, how changes are handled and how quickly you will see working software. A slightly higher price with a smaller, clearer first release and visible progress every two weeks is usually the safer choice.

If you are still deciding whether to build at all, read our comparison of custom software and SaaS, and our guide to replacing spreadsheets with a proper system.