Most selection processes evaluate a company through its sales function - a proposal, a capability deck, a reference call arranged by the vendor. All three are curated. Technical due diligence means evaluating the thing you are actually buying, which is a team's engineering judgement, and it takes about ninety minutes if you ask the right things.
Start by asking to meet the engineers who would do the work, not the account team, and to walk through a system they built for someone else - architecture only, no confidential detail required. What you are listening for is not whether the architecture is impressive. It is whether they can explain why they chose it, what the alternatives were, and what they would do differently now. An engineer who says they would change nothing has either not operated the system long enough to find out, or is not being straight with you.
Then ask about a failure. Specifically: describe an incident in production, what caused it, how it was detected, and what changed afterwards. Every team that has run real systems has these stories, and the good ones tell them without defensiveness. A firm that claims never to have had a serious incident is telling you either that they have not run anything at scale, or that they do not have the monitoring to know when things break.
Ask to see their engineering practice rather than hear about it. What does their CI pipeline run on a pull request? What is their test coverage on a comparable project, and can you see the report? How do they handle secrets? How long from commit to production, and who can approve it? These questions are hard to answer convincingly if the practice does not exist, and easy if it does.
On the commercial side, three questions do most of the work. What did your last project cost against the original estimate, and why did it differ - every truthful answer here involves a number that moved, so a firm claiming perfect estimates is either lucky, new, or shading the truth. Who owns the code, accounts and domain during the engagement. And what does leaving look like: what is documented, what is transferred, how long it takes.
Finally, a reference call is worth having but worth structuring. Ask the reference what went wrong rather than what went well, ask whether the team that started the project finished it, and ask whether they would use the vendor again for something harder. That last question is the most revealing one in the whole process, because it separates a client who was satisfied from a client who was impressed.
None of this requires you to be technical yourself. Bring someone who is if you can. But the pattern you are looking for is consistent across every question above: specificity, willingness to describe failure, and answers that survive a follow-up. Vendors who are good at the work find these questions easy. Vendors who are good at winning work find them uncomfortable, and that discomfort is the signal you came for.
