12 questions to ask before you outsource software development

Picking a software partner is usually done on portfolio, price and a good first call. Those matter, but they say little about what happens in month four, when requirements shift, a key developer leaves, or production goes down on a Friday evening.

These are the questions we would ask if we were on your side of the table.

About the people

1. Who exactly will work on my project, and can I meet them before signing? The people on the sales call are often not the people who write the code. Ask to meet the tech lead and at least one developer. Ask what happens if one of them leaves.

2. Who reviews the code, and how? “We do code reviews” is not an answer. Ask who reviews, what they look for, and whether you can see an example of review comments on a real pull request.

3. How do you vet developers? Look for a technical interview and a practical task, assessed by a senior engineer. Ask what percentage of candidates they reject.

About the process

4. What does the first month look like? A good partner can describe discovery concretely: workshops, outputs, decisions. Vague answers here predict vague estimates later.

5. How do you estimate, and what happens when the estimate is wrong? Every estimate is wrong to some degree. You want a partner who explains their confidence level, tracks burn against it weekly, and raises a flag early.

6. How will I see progress? Regular demos of working software beat status reports. Ask for access to the staging environment, the issue tracker and the repository from day one.

7. How are scope changes handled? Changes are normal. What matters is that they are estimated and agreed before they are built, so the budget never surprises you.

About ownership and risk

8. Who owns the code, infrastructure and accounts? The answer should be “you, from day one” — repositories, cloud accounts, domains and third-party services registered to your organisation, not the vendor’s.

9. How do you handle security? Ask about secrets management, dependency scanning, access control to your systems, and how they handle personal data. Ask whether they will sign an NDA and a data processing agreement.

10. What happens after launch? Who fixes bugs, applies security updates and responds to incidents — and how fast? Get response times in writing, or a clear plan for handing the system over to your team.

About fit

11. Have you worked in my domain? Telecom, payments and regulated industries have failure modes that general-purpose teams discover expensively. Domain experience shortens discovery and reduces risk.

12. When would you tell me not to build something? This is the most revealing question. A partner who has never talked a client out of a feature is optimising for billable hours, not your outcome.

The short version

Good partners are specific. They name people, show artefacts, and talk about risks before you ask. If a partner is vague on these twelve questions before the contract, expect them to be vaguer after it.

If you would like to put these questions to us, book a discovery call — we are happy to be interviewed.