Begin with relevant experience, not the length of the client list. Request a couple of engagements that sit close to your stack, and then find out whether those engineers are still with the rag development company. An honest provider will put you on a call with the engineers. Answers that name nobody at this stage usually mean the delivery team is not the team you were shown.
The paperwork needs more attention than the sales deck. Three clauses do most of the work: intellectual property assignment, the NDA, and exit terms and handover. Everything produced must transfer to you once invoices are settled, together with source code, designs and infrastructure as code. Be careful with wording that leaves framework code in the vendor's hands, as this is frequently exactly the piece that locks you in.
Ask where their numbers come from. An honest estimate is accompanied by the assumptions behind it, a breakdown per feature and a range rather than a single number. A fixed-bid deal only makes sense when the specification is complete; in any other case the provider pads the number and you pay for it anyway. A time-and-materials model puts the risk on your side, web development services company so it demands a cap, laravel vs .net comparison regular demos and transparent reporting.
Process matters as much as the number of developers. Find out what happens when the scope changes, who signs off on a feature and how quality assurance works. A team can show you a working build every one or two weeks. Written acceptance criteria remain the only reliable protection against endless rounds of rework.
Before signing, think about the end of the engagement at the start rather than at the end. Insist that the source repository sits on infrastructure you own from the first commit, and that the documentation is refreshed in every sprint. A vendor with nothing to hide accepts it without argument; resistance at this point tells you most of what you need to know.