How to choose a software development partner (hint: not by hourly rate)
Every company choosing a development partner eventually opens a spreadsheet with hourly rates in one column. It feels rigorous. It is also the least predictive number on the sheet.
Software cost is a product of rate, speed, rework and longevity. A team that charges 40% less but produces software that takes twice as long to change is not cheaper — it is a loan with the interest hidden in your future roadmap. So evaluate the things that actually drive total cost.
Ask how they say no
A partner who agrees with everything is not aligned with you — they are avoiding friction until it is too late to matter. In early conversations, describe a feature that is genuinely questionable and watch what happens. Good partners ask what problem it solves. Great ones will tell you not to build it, and what to do instead.
Look at maintainability, not demos
Anyone can show you a polished demo. Ask instead: can we see documentation from a past project (redacted is fine)? What happens when the engineer who built our system leaves? How would another company take over your work? Partners who build for the next developer produce software that stays cheap to change — which is the entire game.
Test the communication before you sign
The quality of your project will closely track the quality of writing and responsiveness you see in the sales process — that is the best behaviour you will ever get. Clear written answers, honest uncertainty (“we would need to check”), and questions about your business are green flags. Instant confident estimates for a system they barely understand are not.
Check the incentives on longevity
Ask what happens after launch. A partner whose model ends at go-live has no incentive to make year two cheap for you. A partner who expects to maintain and evolve the product is betting their own margin on code quality — which quietly aligns their interests with yours.
The questions worth asking
- Which project did you turn down recently, and why?
- What does a hand-over to another team look like?
- Who exactly will work on our product, and can we talk to them?
- What is the worst production incident you have caused, and what changed after it?
- How do we exit this relationship, and what do we keep?
None of these questions appear in a rate card. All of them predict what your software will cost over five years far better than the hourly number does.