Every prospective partner shows you successful work, confident people and a process diagram. None of that distinguishes between them, because everyone has those. What distinguishes them is how they behave under pressure, who actually does the work, and what they do when they are wrong - and you have to ask specifically to find out.
01Who will actually be on the project
The people in the pitch are frequently not the people who will write the code. Ask for the names and CVs of the specific engineers who will be assigned, ask to meet them, and ask what else they are working on during your engagement.
A partner who cannot name them yet is being honest about availability, which is fair. A partner who names impressive people who then never appear has done something else. Putting the named team into the contract is a reasonable request and the response to it is informative in itself.
| Question | Good answer | Warning sign |
|---|---|---|
| Who writes the code? | Named engineers you can meet | Our team, allocated at kickoff |
| What happens if we want to stop? | 30 days, you keep everything | Long lock-in, exit fees |
| Tell us about a project that failed | Specific story, specific lesson | We haven't had one |
| Who owns the IP and when? | You, from the first commit | On final payment |
| What is your average tenure? | A number, offered readily | Deflection |
02Ask about a failure, and listen to the shape of the answer
Every partner with real history has had a project go badly. The ones worth working with will tell you about one, describe their part in it, and explain what they changed. The answer 'we haven't really had that happen' means either very little experience or an unwillingness to be straight with you, and neither is what you want.
What you are testing is whether they can be honest when it is not flattering, because that is precisely the capability you need in month four when something is going wrong and you need to hear about it early rather than at the end of the sprint.
03Check the exit before you check the entry
Read the termination clause first. How much notice, what happens to work in progress, when does IP transfer, and what does it cost to leave. A partner confident in their work makes leaving easy, because they expect you not to want to.
Lengthy lock-ins, IP that transfers only on final payment, and exit fees are all mechanisms for keeping clients who want to leave. Their presence tells you something about how the relationship is expected to go.
04Reference calls, asked properly
Any reference a vendor provides will say good things. Get value by asking specific questions: what went wrong and how was it handled, did the estimate hold, were the people who pitched the ones who worked on it, and would you use them for something more critical next time.
The most useful question is the last one, because the answer to 'would you hire them again for something harder' is much more discriminating than 'were you satisfied'. Ask for a reference from a project that did not go smoothly, too - the refusal or willingness is itself data.
| Ask | You are learning |
|---|---|
| What went wrong, and how did they handle it? | Behaviour under pressure |
| Did the estimate hold? What changed? | Estimation honesty |
| Were the pitch people the delivery people? | Bait and switch |
| How did they raise bad news? | Early or late |
| Would you use them for something harder? | Genuine confidence |
05Run a small paid trial
The most reliable evaluation is two to four weeks of real, paid work on something genuinely useful. It reveals communication style, code quality, how they handle ambiguity and whether the named engineers are the actual engineers - none of which a proposal can tell you.
It costs a fraction of a full engagement and prevents the far more expensive mistake of discovering the mismatch in month three. A partner who refuses a paid trial on reasonable terms is telling you something about their confidence in what you would find.
Topics
Lena Voss
Lead Architect · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.
Talk to an engineer