Start with proven experience, not the length of the client list. Ask to see three or four case studies that match your technology stack, and then ask whether those engineers are still with the company. A serious vendor will introduce you to the people who would work on your project. Vague answers at this stage almost always mean the demo work came from somewhere else.

The contract warrants more attention than the sales deck. Three sections matter more than the rest: assignment of intellectual property, the NDA, time and materials contract termination and handover. Every artifact has to transfer to you as it is paid for, including documentation, pipelines and deployment scripts. Look closely at any clause that leaves reusable components outside the transfer, because it is usually the part you cannot replace later.

Find out how the estimate was built. A credible 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 works only when the scope is genuinely frozen; in any other case the vendor prices the risk in and you pay for uncertainty either way. Hourly billing moves the risk back to the client, so it requires visible weekly reporting and a spending cap.

How the work is run matters more than headcount. Establish how a new requirement enters the plan, who defines done and how testing is organised. A team should be able to show you a working build every one or two weeks. Clear, written acceptance criteria stay the only reliable protection against endless rounds of rework.

Last, think about the handover while the relationship is still good. Insist that the repository sits in your organisation from day one, and that documentation is updated as part of the work. A vendor real estate software development with nothing to hide accepts it without argument; a long negotiation over it tells you quite a lot.