Begin with domain experience, not the size of the portfolio. Request three or four projects that sit close to your domain and your stack, and edtech web development services then ask specifically which engineers actually built it. A solid partner will put you on a call with the people who would work on your project. Evasive answers at this stage generally mean the delivery team is not the team you were shown.
The paperwork needs more attention than the sales deck. A few clauses carry most of the weight: assignment of intellectual property, non-disclosure, and exit terms and handover. Every artifact has to transfer to you once invoices are settled, along with designs, scripts and infrastructure configuration. Be careful with wording that leaves reusable components in the vendor’s hands, since that is often the part you cannot replace later.
Find out how the estimate was built. A credible estimate comes with a written set of assumptions, a breakdown by feature or module and an explicit range. A fixed price works only when the specification is complete; in any other case the provider adds a risk premium and you fund the buffer regardless. A time-and-materials model shifts that risk to you, so it demands a cap, regular demos and transparent reporting.
The delivery process matters as much as headcount. Find out what happens when the scope changes, who writes the acceptance criteria and how software outsourcing works quality assurance works. A team can show you running software rather than status reports. Clear, written acceptance criteria remain the only reliable protection against an argument at delivery time.
Last, consider the end of the engagement at the start rather than at the end. Ask that the repository sits under your account from the beginning, and that documentation is written as you go rather than left to the end. A provider confident in its own work says yes immediately; resistance at this point tells you most of what you need to know.