A buyer's guide to choosing an engineering partner

We are writing a guide to evaluating firms like ours, which is an obvious conflict of interest. We have handled it by including the questions we find hardest to answer well. If a competitor answers them better than we do, you should hire them.

Questions about the team

The single most common failure mode in this industry is the pitch team and the delivery team being different people. Ask directly, and get the answer in the contract.

• Which of the people in this room will be on the project, and for what proportion of their time?
• What is your average tenure? High churn means your knowledge leaves with them.
• Who replaces someone who leaves mid-project, and how long does that take?
• Can we interview the proposed team leads?

Questions about how they work

• How often do you deploy to production on a typical project?
• What is your test strategy, and what do you deliberately not test?
• Show us a real architecture decision record from a recent project.
• When did you last tell a client not to build something?

That last question is the useful one. A partner who has never talked a client out of a feature is either extraordinarily lucky or not paying attention.

Questions about the ending

Most evaluations focus on starting. The expensive part is leaving.

• What exactly is handed over, and is it in the contract or a promise?
• How long would it take our team to operate this without you?
• What happens to environments, credentials and infrastructure you provisioned?
• Have you completed a handover before? Can we speak to that client?

Commercial terms that matter

Day rate is the most visible number and rarely the most important one. A cheaper team that takes twice as long costs more and takes longer, which is the worst available combination.

1. IP ownership from the first commit, not on final payment
2. Named team members with a substitution notice period
3. Handover as a deliverable phase with acceptance criteria
4. A termination clause you could actually invoke without losing the work
5. Scope review cadence, so change is a conversation rather than a change request

Warning signs

• A fixed price for a build they have not scoped — the risk is priced in and you are paying it
• No questions about your existing systems during the pitch
• Certifications and partnerships presented in place of delivered outcomes
• Reluctance to let you speak to a client whose project went badly

Using the scorecard

The download below is the evaluation grid we would want a client to use on us: weighted criteria across team, process, commercial terms and exit, with space for the evidence behind each score rather than a gut impression.