Start with relevant experience, not the length of the client list. Ask for two or three engagements that resemble your stack, and then find out who actually wrote that code. A solid partner will introduce you to the people who would work on your project. Answers that name nobody at this stage usually mean the delivery team is not the team you were shown.
The paperwork warrants more scrutiny than the proposal. A few clauses carry most of the weight: custom azure development intellectual property assignment, non-disclosure, and termination and handover. Every artifact should transfer to you as it is paid for, together with designs, scripts and infrastructure configuration. Look closely at wording that leaves framework code outside the transfer, since that is often exactly the piece that locks you in.
Ask where their numbers come from. A serious estimate comes with the assumptions behind it, a breakdown per feature and a best case and a worst case. A fixed-price contract only makes sense when the specification is complete; when the scope is still moving the vendor prices the risk in and you fund the buffer regardless. Time and materials shifts that risk to you, so it requires visible weekly reporting and a spending cap.
The delivery process matters more than the number of react developers for hire. Find out how a new requirement enters the plan, who signs off on a feature and what the QA setup looks like. A well-run team will be able to walk you through a working build every one or two weeks. Clear, written acceptance criteria remain the practical protection against endless rounds of rework.
Before signing, consider the day you no longer need this vendor while the relationship is still good. Require that the source repository sits in your organisation from day one, and that documentation is updated as part of the work. A vendor with nothing to hide says yes immediately; hesitation here says quite a lot.