A number produced without questions should be treated as a warning, not a service level. A competent team will come back with clarifying questions before any number: about who owns the data and what happens on failure. A provider that quotes before understanding the scope is working from a template, and that guess becomes a change request later — and you will pay for it consulting services.

Watch for a gap between the people you meet and those who eventually appear in the repository. Ask for named engineers in the contract, with a clause covering replacement. A vendor that only offers a pool of resources and will not commit to individuals is keeping its own flexibility at your cost.

Insist on the source repository from the start. A provider that hands over nothing between demos is asking you to take delivery on faith. Visible commits reveal how many people are really working far better than any status report. The same applies to the build and deployment setup: if it does not exist, assurances about quality remain unverifiable.

Ambiguous wording in the contract around IP is rarely a formality. The document needs to state in plain terms that all deliverables transfer to your ongoing software support company on payment. Also check the governing law and the payment schedule: a large upfront payment with no milestone tied to it takes away any leverage you would otherwise keep.

Lastly, pay attention to the working rhythm. Confirm how much working-time overlap you will share each day, which named person handles your questions and within what time. Some genuine overlap is normally sufficient; zero overlap turns every clarification into a day of delay. Careless writing in the early emails will not improve later.