Start with proven experience, not the size of the portfolio. Ask to see three or four engagements that match your domain and your stack, and then ask who actually wrote that code. A solid partner will put you on a call with the engineers. Answers that name nobody at this stage almost always mean the demo work came from somewhere else.

The paperwork warrants more attention than the sales deck. A few clauses carry most of the weight: ownership of the code, the NDA, software livewire and notice periods and handover. Every artifact has to transfer to you as it is paid for, together with designs, scripts and infrastructure configuration. Be careful with wording that leaves reusable components in the vendor's hands, because that is often the dependency that makes switching painful.

Ask where their numbers come from. A serious estimate is accompanied by the assumptions behind it, a task-level breakdown 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 vendor pads the number and you pay for offshore development rates it anyway. A time-and-materials model shifts that risk to you, so it requires a sprint cadence, demos and a budget cap.

How the work is run matters as much as the number of developers. Find out how change requests are handled, who writes the acceptance criteria and how quality assurance works. A team will be able to demonstrate a live build at the end of each sprint. Written acceptance criteria are your only real protection against endless rounds of rework.

Finally, consider the handover before it becomes urgent. Ask that the code repository stays in your organisation from day one, and that documentation is updated as part of the work. A provider confident in its own work accepts it without argument; resistance at this point reveals most of what you need to know.