Software
Evaluate on how they handle ambiguity, what they say about maintenance, and whether your team could take the code over. Portfolio screenshots say almost nothing about whether a system will survive its third year.
A partner who immediately estimates has not understood it; one who asks what happens in the edge cases, what the data looks like and who uses it, is doing the work that prevents expensive surprises later.
Who updates dependencies, how security patches reach production, what the deployment process is, what happens if the original developers leave. A partner uninterested in these questions is optimising for delivery day rather than for the years after it.
Code in your repositories, infrastructure in your accounts, documentation written for someone who was not there. If leaving would be difficult, that difficulty is a commercial position rather than a technical fact.
Testing and review practice is the clearest quality proxy available before you commit.
Ask how changes are reviewed and what is tested automatically. 'We test manually before release' is an honest answer that tells you exactly what the third year will cost.
Yes, and it should live in your repositories with infrastructure in your accounts from the start. Ownership arranged at the end of a project is ownership you will negotiate for at the worst possible moment.
What happens when the people who built it are gone. The answer covers documentation, testing, deployment and handover in one, and it is the question suppliers optimising for delivery day answer least convincingly.
Evaluate on how they handle ambiguity, what they say about maintenance, and whether your team could take the code over. Portfolio screenshots say almost nothing about whether a system will survive its third year.
You have read what we think. If you want to know what it means for your case specifically, describe it and we will tell you which parts of how to evaluate a software development partner actually apply — and which do not.
