Start with domain experience, not the length of the client list. Ask to see three or four engagements that match your technology stack, and then find out who actually wrote that code. A serious vendor is happy to connect you with the people who would work on your project. Answers that name nobody at this stage generally mean the delivery team is not the team you were shown.
The contract needs a slower read than the pitch. A few clauses carry most of the weight: intellectual property assignment, non-disclosure, and termination and handover. Every artifact should transfer to you on payment, along with designs, erp implementation services scripts and infrastructure configuration. Be careful with language that leaves so-called reusable libraries with the vendor, nearshore software development since that is often exactly the piece that locks you in.
Find out how the estimate was built. An honest estimate arrives with a list of assumptions, a breakdown per feature and a best case and a worst case. A fixed-price contract works only when the specification is complete; otherwise the vendor adds a risk premium and you pay for it anyway. Hourly billing shifts that risk to you, so it needs a cap, regular demos and transparent reporting.
How the work is run matters as much as team size. Find out how a new requirement enters the plan, who defines done and how quality assurance works. A well-run hire development team should be able to walk you through a live build at the end of each sprint. Clear, written acceptance criteria remain the practical protection against endless rounds of rework.
Last, plan for the end of the engagement while the relationship is still good. Insist that the source repository lives in your organisation from the first commit, and that the documentation is refreshed in every sprint. A partner who is comfortable with this will agree quickly; a long negotiation over it says most of what you need to know.