Look first at proven experience, not the size of the portfolio. Ask for two or three engagements that resemble your technology stack, python vs php performance and then ask specifically whether those engineers are still with the company. An honest provider is happy to connect you with the people who would work on your project. Vague answers at this stage generally mean the demo work came from somewhere else.
The agreement needs more attention than the sales deck. Three clauses do most of the work: assignment of intellectual property, non-disclosure, and termination and handover. All the work product should transfer to you once invoices are settled, together with designs, scripts and infrastructure configuration. Be careful with language that keeps framework code in the vendor's hands, since it is usually the part you cannot replace later.
Ask how they estimate. A serious estimate comes with the assumptions behind it, a breakdown by feature or module and a range rather than a single number. A fixed-bid deal only makes sense when the scope is genuinely frozen; otherwise the provider prices the risk in and hire edtech developers you fund the buffer regardless. Hourly billing moves the risk back to the client, so it requires visible weekly reporting and a spending cap.
How the work is run beats headcount. Find out what happens when the scope changes, who writes the acceptance criteria and what the QA setup looks like. A well-run team should be able to demonstrate a working build every one or two weeks. Written acceptance criteria stay the practical protection against an argument at delivery time.
Finally, plan for the handover at the start rather than at the end. Ask that the repository stays in your organisation from the beginning, and that a readme and architecture notes are kept current as the code changes. A vendor with nothing to hide says yes immediately; resistance at this point tells you a great deal.