Look first at proven experience, not the size of the portfolio. Ask to see two or three engagements that sit close to your stack, and then ask specifically whether those engineers are still with the company. A serious vendor will introduce you to the engineers. Answers that name nobody at this stage usually mean the delivery team is not the team you were shown.
The contract warrants more attention than the sales deck. Three sections matter more than the rest or graphql: ownership of the code, confidentiality, and notice periods and handover. All the work product has to transfer to you once invoices are settled, together with source code, designs and infrastructure as code. Look closely at language that keeps framework code in the vendor's hands, because that is often the dependency that makes switching painful.
Ask how they estimate. A credible estimate comes 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 requirements are stable and documented; in any other case the vendor prices the risk in and you pay for uncertainty either way. Time and materials shifts that risk to you, so it requires a cap, regular demos and custom laravel development transparent reporting.
The delivery process beats headcount. Ask how a new requirement enters the plan, livewire vs vue who writes the acceptance criteria and how testing is organised. A team should be able to demonstrate a working build every one or two weeks. Written acceptance criteria remain your only real protection against endless rounds of rework.
Finally, think about the day you no longer need this vendor while the relationship is still good. Require that the code repository stays in your organisation from the beginning, 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 tells you a great deal.
