Start with domain experience, not the length of the client list. Ask to see two or three case studies that match your technology stack, and then ask specifically who actually wrote that code. A solid partner will put you on a call with the people who would work on your project. Answers that name nobody at this stage generally mean the demo work came from somewhere else.

The agreement deserves more scrutiny than the proposal. Three sections matter more than the rest: assignment of intellectual property, the NDA, choosing between laravel and node js exit terms and handover. Every artifact has to transfer to you on payment, including source code, designs and infrastructure as code. Watch for wording that leaves so-called reusable libraries with the vendor, since that is often the part you cannot replace later.

Find out how the estimate was built. A credible estimate is accompanied by a list of assumptions, a breakdown by feature or custom llm development module and an explicit range. A fixed price only makes sense when the scope is genuinely frozen; in any other case the provider prices the risk in and you fund the buffer regardless. A time-and-materials model moves the risk back to the client, so it requires visible weekly reporting and a spending cap.

The delivery process matters as much as the number of developers. Establish what happens when the scope changes, who defines done and how quality assurance works. A mature team will be able to show you a working build every one or two weeks. Clear, written acceptance criteria remain the practical protection against the it-was-never-in-scope conversation.

Last, consider the handover before it becomes urgent. Insist that the code repository sits in your organisation from the first commit, and that a readme and architecture notes are kept current as the code changes. A provider confident in its own work says yes immediately; resistance at this point tells you a great deal.