Look first at domain experience, not the length of the client list. Ask to see two or three engagements that match your stack, and then ask which engineers actually built it. An honest provider is happy to connect you with the tech lead. Evasive answers at this stage almost always mean the demo work came from somewhere else.
The contract deserves more scrutiny than the proposal. Three clauses do most of the work: ownership of the code, web application development for edtech non-disclosure, and termination and handover. All the work product has to transfer to you as it is paid for, together with designs, scripts and infrastructure configuration. Be careful with wording that leaves framework code outside the transfer, because it is usually the dependency that makes switching painful.
Find out how the estimate was built. A serious estimate is accompanied by a list of assumptions, a breakdown per feature and a best case and a worst case. A fixed-price contract is only reasonable when the requirements are stable and documented; otherwise the provider prices the risk in and you fund the buffer regardless. A time-and-materials model moves the risk back to the client, llm integration services so it demands a cap, regular demos and transparent reporting.
The delivery process matters more than headcount. Find out what happens when the scope changes, who signs off on a feature and how testing is organised. A mature team can show you a working build every one or two weeks. Clear, written acceptance criteria remain the practical protection against the it-was-never-in-scope conversation.
Finally, consider the day you no longer need this vendor before it becomes urgent. Require that the repository sits under your account from day one, and that documentation is updated as part of the work. A vendor with nothing to hide accepts it without argument; hesitation here tells you most of what you need to know.
