Start with relevant experience, not the length of the client list. Request a couple of case studies that resemble your stack, and then ask whether those engineers are still with the python web development company. A solid partner which is better monolith or microservices happy to connect you with the people who would work on your project. Answers that name nobody at this stage almost always mean the demo work came from somewhere else.

The paperwork warrants more scrutiny than the proposal. A few clauses carry most of the weight: ownership of the code, non-disclosure, and exit terms and handover. Everything produced has to transfer to you once invoices are settled, including source code, designs and infrastructure as code. Watch for any clause that keeps reusable components in the vendor's hands, since it is langchain a rag framework usually the part you cannot replace later.

Ask where their numbers come from. A credible estimate comes with the assumptions behind it, a breakdown per feature and an explicit range. A fixed-bid deal works only when the requirements are stable and documented; in any other case the vendor prices the risk in and you fund the buffer regardless. Hourly billing moves the risk back to the client, so it requires a cap, regular demos and transparent reporting.

How the work is run beats the number of developers. Establish how a new requirement enters the plan, who defines done and what the QA setup looks like. A well-run team should be able to demonstrate running software rather than status reports. Written acceptance criteria remain your only real protection against endless rounds of rework.

Finally, think about the day you no longer need this vendor before it becomes urgent. Require that the code repository stays under your account from the first commit, and that the documentation is refreshed in every sprint. A provider confident in its own work will agree quickly; hesitation here says quite a lot.