This is an old revision of the document!
Look first at domain experience, not the size of the portfolio. Request a couple of projects that match your technology stack, and then ask specifically which engineers actually built it. A serious vendor is happy to connect you with the engineers. Evasive answers at this stage generally mean the demo work came from somewhere else.
The paperwork warrants more scrutiny than the proposal. Three clauses do most of the work: assignment of intellectual property, confidentiality, and termination and handover. Everything produced has to transfer to you as it is paid for, including documentation, pipelines and deployment scripts. Watch for wording that keeps framework code outside the transfer, because it is usually the part you cannot replace later.
Ask how they estimate. A credible estimate comes with the assumptions behind it, why hire a dedicated team instead of freelancers breakdown by feature or module and a best case and a worst case. A fixed-bid deal only makes sense when the scope is genuinely frozen; when the scope is still moving the vendor prices the risk in and ai in custom software development you pay for it anyway. Hourly billing puts the risk on your side, vue vs livewire so it needs visible weekly reporting and a spending cap.
Process matters more than headcount. Find out how change requests are handled, who writes the acceptance criteria and what the QA setup looks like. A well-run team can demonstrate a live build at the end of each sprint. Acceptance criteria in writing remain the only reliable protection against the it-was-never-in-scope conversation.
Finally, plan for the day you no longer need this vendor at the start rather than at the end. Require that the code repository sits under your account from the beginning, and that the documentation is refreshed in every sprint. A vendor with nothing to hide accepts it without argument; a long negotiation over it says most of what you need to know.