Start with ownership boundaries
Clarify who owns repositories, cloud accounts, domains, data, credentials and deployment access.
Your business should be able to continue operating the product if the vendor relationship changes.
Evaluate engineering process
Ask how architecture decisions are documented, how code review works, which tests block releases and how incidents are handled.
A transparent process is easier to govern than one that relies on individual heroics.
Security should be contractual and technical
Access should follow least privilege, secrets should be managed centrally and offboarding should remove credentials quickly.
Security responsibility needs named owners and auditable controls.
Communication needs operating rhythm
Define product decision makers, engineering leads, escalation paths, reporting cadence and expected response times.
Good communication is structured around decisions and risks, not constant meetings.
Compare total delivery cost
Include rework, delayed releases, support burden, vendor lock-in and incident risk in the comparison.
The strongest vendor is often the one that makes progress and risk visible early.
Run vendor selection like a product risk review
Before signing a long engagement, use a focused technical discovery or paid/defined pilot if appropriate to test communication, architecture judgment, code quality and delivery visibility. The objective is to learn how the team behaves when requirements are incomplete or a technical risk appears.
Document exit conditions from day one: repository ownership, infrastructure access, documentation expectations, credential rotation and handover format. A vendor relationship is healthier when both sides know the product can continue without operational hostage risk.