Begin with domain experience, not the length of the client list. Request a couple of case studies that resemble your domain and your stack, and then ask specifically which engineers actually built it. An honest provider is happy to connect you with the tech lead. Evasive answers at this stage generally mean the delivery team is not the team you were shown.
The agreement deserves more scrutiny than the proposal. Three clauses do most of the work: intellectual property assignment, non-disclosure, and exit terms and difference between nearshore and offshore development handover. Everything produced must transfer to you on payment, including source code, designs and infrastructure as code. Look closely at language that keeps framework code outside the transfer, since that is often the part you cannot replace later.
Ask how they estimate. A credible estimate arrives with a written set of assumptions, a breakdown per feature and a range rather than a single number. A fixed-price contract is only reasonable when the scope is genuinely frozen; in any other case the provider pads the number and you fund the buffer regardless. Time and materials shifts that risk to you, so it requires visible weekly reporting and a spending cap.
How the work is run matters as much as the number of hire react developers. Ask how change requests are handled, who writes the acceptance criteria and how testing is organised. A well-run team will be able to walk you through a live build at the end of each sprint. Written acceptance criteria remain the only reliable protection against an argument at delivery time.
Before signing, consider the end of the engagement while the relationship is still good. Ask that the repository lives on infrastructure you own from the first commit, and that the documentation is refreshed in every sprint. A provider confident in its own work accepts it without argument; a long negotiation over it reveals most of what you need to know.