Start with domain experience, not the number of logos on the website. Request a couple of engagements that resemble your stack, hire scikit learn developer and then ask specifically who actually wrote that code. A solid partner will introduce you to the people who would work on your project. Vague answers at this stage usually mean the demo work came from somewhere else.

The paperwork needs more scrutiny than the proposal. Three sections matter more than the rest: ownership of the code, confidentiality, and notice periods and handover. All the work product must transfer to you once invoices are settled, including designs, scripts and infrastructure configuration. Be careful with language that keeps reusable components outside the transfer, since this is frequently the part you cannot replace later.

Ask where their numbers come from. A credible estimate arrives with the assumptions behind it, a breakdown per feature and a best case and a worst case. A fixed-bid deal works only when the requirements are stable and documented; when the scope is still moving the provider prices the risk in and you pay for it anyway. Hourly billing shifts that risk to you, so it requires a cap, regular demos and transparent reporting.

How the work is run beats the number of developers. Find out how a new requirement enters the plan, who signs off on a feature and what the QA setup looks like. A mature team can demonstrate running software rather than status reports. Acceptance criteria in writing remain the only reliable protection against endless rounds of rework.

Before signing, think about the day you no longer need this vendor while the relationship is still good. Insist that the source repository lives in your organisation from day one, outsource web application development and that documentation is written as you go rather than left to the end. A partner who is comfortable with this will agree quickly; a long negotiation over it tells you a great deal.