A practical guide to choosing a software development partner

Choosing a software partner affects delivery, maintainability and ongoing costs. A demo and a price are useful inputs, but they do not show how an engagement will work. Use the following questions to guide a more complete evaluation.

Ask about the boring things

• What ownership and usage rights apply to custom code, third-party components and pre-existing tools? Record the agreed rights in writing.
• Where does documentation live, and can we see a sample from a past project?
• What happens if we part ways — what's the handover obligation?
• How do you test? Ask to see an actual test suite, not a testing 'philosophy'
• Who exactly will work on our project, and can we meet them before signing?

Weigh the process, not the promises

Ask how discovery, demonstrations, releases and change control work. A fixed-price proposal should make its assumptions, exclusions and acceptance criteria clear. Compare the proposed process with your own review capacity.

Red flags worth walking away from

• Reluctance to put IP ownership in the contract
• No live, referenceable clients you can actually call
• A demo that can't go off-script
• Pressure to commit before a written scope exists
• A very low bid without a clear explanation of scope, exclusions and ongoing costs

The cheapest bid and the most expensive bid are both information. The question is what the middle knows that the edges don't.

What good looks like

Consider a discovery phase or pilot when uncertainty is high. Agree deliverables, acceptance criteria, ongoing costs and handover arrangements before committing to a larger scope. Discovery may produce a validated scope and roadmap rather than production software.