Start with relevant experience, not the number of logos on the website. Ask for three or four case studies that resemble your stack, and then find out which engineers actually built it. A serious vendor will introduce you to the engineers. Evasive answers at this stage generally mean the demo work came from somewhere else.
The contract deserves more scrutiny than the proposal. Three clauses do most of the work: assignment of intellectual property, non-disclosure, and exit terms and handover. Everything produced has to transfer to you as it is paid for, including designs, scripts and infrastructure configuration. Watch for wording that leaves framework code with the vendor, because it is usually the part you cannot replace later.
Find out how the estimate was built. A serious estimate arrives with a list of assumptions, a breakdown by feature or module and a best case and a worst case. A fixed-bid deal only makes sense when the requirements are stable and documented; in any other case the vendor pads the number and you pay for uncertainty either way. A time-and-materials model puts the risk on your side, so it requires visible weekly reporting and laravel vs rails a spending cap.
How the work is run beats the number of developers. Establish what happens when the scope changes, who defines done and what the QA setup looks like. A team can demonstrate a live build at the end of each sprint. Clear, written acceptance criteria stay your only real protection against the it consulting services-was-never-in-scope conversation.
Last, think about the end of the engagement while the relationship is still good. Ask that the code repository sits in your organisation from the beginning, and that documentation is written as you go rather than left to the end. A partner who is comfortable with this will agree quickly; hesitation here says most of what you need to know.