Look first at domain experience, not the length of the client list. Ask for a couple of engagements that sit close to your stack, and then ask whether those engineers are still with the company. A solid partner is happy to connect you with the engineers. Answers that name nobody at this stage almost always mean the delivery team is not the team you were shown.
The agreement warrants a slower read than the pitch. Three clauses do most of the work: ownership of the code, the NDA, and termination and handover. All the work product should transfer to you as it is paid for, along with designs, scripts and infrastructure configuration. Be careful with wording that keeps reusable components outside the transfer, dedicated teams as this is frequently the dependency that makes switching painful.
Find out how the estimate was built. A credible estimate is accompanied by a written set of assumptions, livewire vs react comparison a task-level breakdown and an explicit range. A fixed-price contract is only reasonable when the scope is genuinely frozen; when the scope is still moving the supplier pads the number and you fund the buffer regardless. A time-and-materials model moves the risk back to the client, so it requires a cap, regular demos and transparent reporting.
Process beats team size. Ask how change requests are handled, who defines done and how quality assurance works. A team can walk you through a working build every one or two weeks. Acceptance criteria in writing stay your only real protection against an argument at delivery time.
Finally, plan for the day you no longer need this vendor at the start rather than at the end. Ask that the source repository lives on infrastructure you own from day one, and that documentation is updated as part of the work. A provider confident in house vs outsourcing software development its own work will agree quickly; hesitation here reveals most of what you need to know.
