Begin with relevant experience, not the number of logos on the website. Ask to see a couple of engagements that match your stack, and then ask specifically which engineers actually built it. A solid partner will introduce you to the people who would work on your project. Answers that name nobody at this stage generally mean the delivery team is not the team you were shown.
The contract needs more attention than the sales deck. Three clauses do most of the work: ownership of the code, non-disclosure, and edtech web development services notice periods and handover. Every artifact must transfer to you once invoices are settled, together with source code, retail software development designs and infrastructure as code. Be careful with wording that keeps reusable components with the vendor, because that is often exactly the piece that locks you in.
Ask how they estimate. A serious estimate comes with a list of assumptions, a task-level breakdown and a range rather than a single number. A fixed-price contract only makes sense when the scope is genuinely frozen; otherwise the vendor prices the risk in and you fund the buffer regardless. A time-and-materials model puts the risk on your side, so it demands a sprint cadence, demos and a budget cap.
How the work is run matters as much as the number of developers. Find out how a new requirement enters the plan, who writes the acceptance criteria and how testing is organised. A team can show you a working build every one or two weeks. Clear, written acceptance criteria stay the practical protection against the it-was-never-in-scope conversation.
Finally, think about the end of the engagement while the relationship is still good. Require that the source repository stays under your account from day one, and that a readme and architecture notes are kept current as the code changes. A vendor with nothing to hide will agree quickly; a long negotiation over it tells you most of what you need to know.
