Ten questions to ask a custom software development company

1. Who owns the code when the project ends?

Good answer: "IP assigns to you on payment, in writing, covering all deliverables - here's the clause." Bad answer: "You'll be able to use the software" (this describes a licence, not ownership). See who owns the code for the full checklist behind this one.

2. What happens if requirements change mid-project?

Good answer: a described change-request process with how it's priced and how it affects timeline. Bad answer: "We're flexible, don't worry about it" - flexible with no process usually means expensive later, agreed verbally rather than in writing.

3. Can I speak to a past client, ideally one where something went wrong?

Good answer: a willingness to provide a reference and openness about a project that hit problems and how they were resolved. Bad answer: only offering references for their smoothest, easiest projects, or refusing outright.

4. How do you price this - fixed, day rate, or a mix?

Good answer: a clear explanation of the model and why it fits your specific requirements, referencing how settled your scope is. Bad answer: a single headline number with no scope attached - see fixed price vs day rate for what should sit behind either.

5. What happens if I want to leave partway through?

Good answer: clear terms on what you're entitled to (code, documentation) at any exit point, and notice periods. Bad answer: vague or evasive, or a contract that only mentions termination in the supplier's favour.

6. Who will actually work on my project?

Good answer: named individuals, their experience, and whether the same people stay on the project throughout. Bad answer: "our team" with no named individuals - a sign work may be handed to whoever's free, or subcontracted without you knowing.

7. What does support look like after launch, and what does it cost?

Good answer: a specific support offering - response times, hours covered, what's included - priced separately from the build. Bad answer: "we'll sort something out" with nothing in writing before you sign.

8. How do you handle security and data protection?

Good answer: concrete practices (access control, data encryption, how they handle personal data under UK GDPR) and awareness of your specific compliance obligations. Bad answer: a generic assurance with no specifics, or no awareness of the ICO guidance relevant to your sector.

9. What happens if you go out of business or the project stalls?

Good answer: honesty about the risk, discussion of repository access and, for larger projects, willingness to discuss escrow. Bad answer: dismissing the question as unlikely rather than answering it - every business, including agencies, carries this risk.

10. Why would you turn this project down?

Good answer: a specific, honest scenario - "if your process is genuinely standard, we'd tell you to buy something off-the-shelf instead" - showing they'll say no when it's the right answer. Bad answer: "we can build anything", which tells you nothing about their judgement, only their willingness to take the fee.

Using this list well

Ask these of two or three suppliers and compare the answers side by side, not just the price. Combine it with a proper written brief before you go into these conversations - see how to write a software brief - so the answers you get are about the supplier's approach, not a scramble to understand what you actually need.

If you want to run this list past us directly, get in touch and ask away - we'd rather answer these honestly on a call than have you find the gaps after signing. Our pricing page also covers question 4 in more depth.