A quote that comes back within a day counts as a bad sign. A competent team responds with clarifying questions before any number: about users and volumes. A vendor that commits to a figure before understanding the scope is probably pricing a guess, and that guess becomes a change request later — at your expense.
Be wary of a gap between the people you meet and the developers actually assigned. Request named engineers in the contract, with a provision that requires notice before anyone is swapped. A team that will only describe a pool of resources and refuses to name specific engineers is preserving the right to assign anyone it likes.
Require access to the repository from the first week. A provider that hands over a build only at the end of each phase expects you to take delivery on faith. Daily commits tell you who is really on the project far better than a weekly report. This extends to the build and edtech web development deployment setup: if it does not exist, quality claims are nothing more than words.
Vague wording in the contract around code ownership is never an oversight. The contract should state explicitly that all deliverables transfer to your company as they are paid for. Look too at which is better monolith or microservices country’s law applies and how payments are structured: heavy prepayment with no milestone tied to it eliminates your only leverage.
Lastly, examine how they communicate. Confirm how much working-time overlap there will be with your timezone, which person answers day-to-day questions and within what time. Some genuine overlap generally works; none at all converts each small question into a twenty-four hour round trip. Sloppy written English in the sales phase does not improve later.