Look first at domain experience, not the length of the client list. Ask to see a couple of projects that sit close to your technology stack, and laravel or django then ask specifically who actually wrote that code. A serious vendor will put you on a call with the people who would work on your project. Vague answers at this stage usually mean the delivery team is not the team you were shown.

The agreement warrants a slower read than the pitch. A few clauses carry most of the weight: intellectual property assignment, non-disclosure, and exit terms and handover. Everything produced should transfer to you once invoices are settled, along with documentation, pipelines and deployment scripts. Look closely at any clause that keeps reusable components with the vendor, because this is frequently the part you cannot replace later.

Find out how the estimate was built. A credible estimate arrives with the assumptions behind it, a breakdown by feature or module and a range rather than a single number. A fixed-bid deal is only reasonable when the scope is genuinely frozen; when the scope is still moving the supplier prices the risk in and you fund the buffer regardless. Hourly billing puts the risk on your side, so it requires a sprint cadence, demos and a budget cap.

The delivery process matters as much as team size. Ask how ai changes software development change requests are handled, who writes the acceptance criteria and what the QA setup looks like. A well-run team will be able to show you running software rather than status reports. Written acceptance criteria stay the practical protection against an argument at delivery time.

Last, consider the handover while the relationship is still good. Ask that the code repository sits under your account from day one, and that the documentation is refreshed in every sprint. A provider confident in its own work accepts it without argument; hesitation here reveals most of what you need to know.