Begin with domain experience, not the length of the client list. Ask web application development for edtech two or three case studies that match your domain and your stack, and custom software development prices then ask specifically which engineers actually built it. A serious vendor will introduce you to the tech lead. Vague answers at this stage almost always mean the demo work came from somewhere else.
The paperwork deserves more scrutiny than the proposal. Three sections matter more than the rest: ownership of the code, confidentiality, and notice periods and handover. Everything produced must transfer to you as it is paid for, azure consulting services together with designs, scripts and infrastructure configuration. Watch for any clause that keeps so-called reusable libraries outside the transfer, as this is frequently the part you cannot replace later.
Ask where their numbers come from. An honest estimate comes with a written set of assumptions, a task-level breakdown and a best case and a worst case. A fixed-price contract is only reasonable when the requirements are stable and documented; otherwise the vendor adds a risk premium and you pay for uncertainty either way. A time-and-materials model shifts that risk to you, so it demands visible weekly reporting and a spending cap.
How the work is run matters as much as the number of developers. Establish how change requests are handled, who writes the acceptance criteria and how quality assurance works. A well-run team can demonstrate a live build at the end of each sprint. Written acceptance criteria stay your only real protection against the it-was-never-in-scope conversation.
Last, think about the handover while the relationship is still good. Require that the repository sits under your account from day one, and that a readme and architecture notes are kept current as the code changes. A partner who is comfortable with this will agree quickly; resistance at this point says quite a lot.