15 Questions to Ask Before Hiring a Software Development Partner

How Most Businesses Choose Development Partners Badly

The typical procurement process for a software development partner looks like this: write a brief (usually vague), send it to three or four agencies found through referrals or Google, receive proposals in different formats that are impossible to compare meaningfully, and choose based on price — or, occasionally, based on which proposal was most confidently written.

This process reliably produces the wrong result because it evaluates the wrong things. Price is a function of scope, and the scope in most briefs is undefined enough that two competent teams could produce proposals that differ by a factor of three. A lower proposal might mean lower hourly rates, or it might mean that the team scoped the project more optimistically — or that they planned to recover the margin through change requests once the project was underway.

15 Questions Worth Asking

These questions are designed to surface the signal that matters — not technical capability, which is relatively easy to verify, but process quality and cultural fit, which are much harder to evaluate and much more consequential for the outcome of a long project.

1. What does your discovery or scoping process look like before a build starts?
2. Can you show me an example of a project brief you produced before starting a build?
3. How do you handle requirements that change mid-project?
4. What does a typical sprint review look like, and who attends?
5. How do you handle technical debt in your own projects?
6. Can you describe a project that did not go well, and what you did about it?
7. Who specifically will be working on my project, and what is their experience?
8. What is your policy on subcontracting work?
9. How do you handle knowledge transfer if the engagement ends?
10. What does your post-launch support model look like?
11. How do you approach security and data privacy by default?
12. What monitoring and alerting do you set up on systems you build?
13. How do you price change requests relative to the original scope?
14. What does your definition of "done" include, beyond working features?
15. How do you ensure the system remains maintainable by a different team if we ever change partners?

Red Flags That Should End the Conversation

The most dangerous partners are not the ones who are incompetent — they are the ones who are competent but misaligned. Technically skilled teams who do not ask questions about your business, who produce proposals within 48 hours of receiving a brief they cannot possibly understand yet, who are unwilling to discuss scope before committing to a price — these are red flags that predict expensive problems, not technical failure.

Other signals to watch for: a proposal that is primarily a list of technologies rather than a description of how the work will be done; team composition that puts senior people in pitches and junior people in delivery; no mention of testing or quality assurance in the proposal; and an unwillingness to provide references from clients in similar industries.

What a Good Proposal Actually Contains

A good proposal is a demonstration of how the team thinks, not just what they will deliver. It should include: evidence that the team understood the problem (often revealed by questions they ask before proposing); a description of their process, not just their output; a clear explanation of what is and is not included in the scope; a realistic timeline with explicit milestones; and a transparent pricing model that distinguishes between fixed and variable costs.

Making the Final Call

After the evaluation is complete, the decision should be primarily about communication and process fit — not price or technical claims. You will be working with this team for months or years. The team that communicates well, responds quickly, acknowledges uncertainty honestly, and demonstrates an interest in your business rather than just your project is almost always the right choice, even if their price is slightly higher.