Look first at domain experience, not the length of the client list. Request two or three case studies that match your domain and your stack, and then ask specifically which engineers actually built it. A solid partner 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 agreement deserves a slower read than the pitch. Three sections matter more than the rest: ownership of the code, the NDA, and notice periods and handover. All the work product has to transfer to you on payment, along with source code, designs and infrastructure as code. Watch for wording that keeps framework code in the vendor's hands, because that is often the dependency that makes switching painful.

Find out how the estimate was built. An honest estimate is accompanied by a written set of assumptions, a breakdown per feature and a range rather than a single number. A fixed-price contract only makes sense when the scope is genuinely frozen; in any other case the provider adds a risk premium and mvp development mistakes to avoid you pay for it anyway. A time-and-materials model shifts that risk to you, so it requires a sprint cadence, demos and a budget cap.

Process matters as much as team size. Ask how a new requirement enters the plan, who defines done and how testing is organised. A team can demonstrate running software rather than status reports. Written acceptance criteria remain the only reliable protection against the it-was-never-in-scope conversation.

Finally, consider the day you no longer need this vendor before it becomes urgent. Ask that the source repository sits in your organisation from the first commit, performance php vs python and that a readme and architecture notes are kept current as the code changes. A provider confident in its own work accepts it without argument; resistance at this point tells you a great deal.