Begin with domain experience, not the length of the client list. Ask for a couple of case studies that sit close to your stack, and then ask specifically who actually wrote that code. A serious vendor is happy to connect you with 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 paperwork warrants more attention than the sales deck. Three sections matter more than the rest: intellectual property assignment, the NDA, and exit terms and handover. Every artifact must transfer to you as it is paid for, along with documentation, langchain and rag difference pipelines and deployment scripts. Watch for language that keeps so-called reusable libraries in the vendor's hands, as this is frequently the dependency that makes switching painful.

Find out how the estimate was built. An honest estimate comes with a written set of assumptions, a task-level breakdown and custom python development a range rather than a single number. A fixed price only makes sense when the requirements are stable and documented; in any other case the supplier adds a risk premium and you pay for uncertainty either way. Time and materials puts the risk on your side, so it requires visible weekly reporting and a spending cap.

Process matters more than the number of developers. Find out what happens when the scope changes, who signs off on a feature and how testing is organised. A well-run team can walk you through a live build at the end of each sprint. Acceptance criteria in writing stay the practical protection against endless rounds of rework.

Finally, consider the end of the engagement while the relationship is still good. Ask that the repository sits on infrastructure you own from the beginning, backend and frontend technologies we use that documentation is written as you go rather than left to the end. A partner who is comfortable with this will agree quickly; a long negotiation over it tells you most of what you need to know.