Start with domain experience, not the length of the client list. Ask to see three or four projects that match your stack, and then ask which engineers actually built it. An honest provider will introduce you to the tech lead. Evasive answers at this stage almost always mean the delivery team is not the team you were shown.
The paperwork deserves more scrutiny than the proposal. A few clauses carry most of the weight: assignment of intellectual property, confidentiality, and termination and handover. Everything produced should transfer to you as it is paid for, including designs, scripts and infrastructure configuration. Look closely at language that leaves framework code in the vendor’s hands, since it is usually the part you cannot replace later.
Ask where their numbers come from. An honest estimate arrives with a written set of assumptions, a breakdown per feature and a best case and a worst case. A fixed price is only reasonable when the specification is complete; in any other case the supplier prices the risk in difference between laravel and symfony you pay for it anyway. time and materials vs fixed price contract and materials moves the risk back to the client, so it demands visible weekly reporting and a spending cap.
The delivery process matters more than the number of developers. Establish what happens when the scope changes, who defines done and how quality assurance works. A team should be able to show you a live build at the end of each sprint. Acceptance criteria in writing stay your only real protection against the it-was-never-in-scope conversation.
Finally, think about the handover before it becomes urgent. Ask that the code repository stays under your account from day one, and that the documentation is refreshed in every sprint. A vendor with nothing to hide says yes immediately; hesitation here says most of what you need to know.