Begin with relevant experience, not the size of the portfolio. Ask to see a couple of projects that sit close to your stack, and then ask whether those engineers are still with the company. A solid partner will put you on a call with the people who would work on your project. Evasive answers at this stage generally mean the delivery team is not the team you were shown.

The paperwork needs more attention than the sales deck. Three sections matter more than the rest: intellectual property assignment, the NDA, and notice periods and handover. All the work product has to transfer to you on payment, together with documentation, pipelines and deployment scripts. Look closely at wording that leaves framework code in the vendor's hands, since this is frequently exactly the piece that locks you in.

Find out how the estimate was built. A serious estimate is accompanied by the assumptions behind it, a breakdown by feature or module and a range rather than a single number. A fixed price is only reasonable when the scope is genuinely frozen; otherwise the supplier prices the risk in and you pay for it anyway. Hourly billing moves the risk back to the client, so it demands a cap, regular demos and transparent reporting.

Process matters more than headcount. Ask what happens when the scope changes, who signs off on a feature and how testing is organised. A mature team should be able to demonstrate a live build at the end of each sprint. Acceptance criteria in writing are the practical protection against an argument at delivery time.

Finally, consider the end of the engagement at the start rather than at the end. Insist that the source repository stays under your account from the first commit, and software development pricing models that the documentation is refreshed in every sprint. A partner who is comfortable with this accepts it consulting services without argument; resistance at this point tells you quite a lot.