Ask for evidence with boundaries
Review public systems, release practices and technical outcomes that can be verified without breaching another client’s confidentiality. Unsupported commercial percentages and vague project counts are weaker than dated architecture and recovery evidence.
Inspect the ownership model
Confirm repository, domain, hosting, provider, data and intellectual-property ownership. Understand which reusable foundations remain supplier IP and which project-specific work transfers to the client.
Review security and access
Require role-specific accounts, protected secrets, least privilege, environment separation and a documented offboarding route. Shared master credentials and production development are warning signs.
Qualify release and recovery
Ask how the partner builds immutable artifacts, tests migrations, verifies public routes, handles indexing and restores a prior healthy release. A rollback claim is credible only when its target and state are explicit.
Agree communication and acceptance
Define overlap hours, written decision records, milestones, acceptance evidence, change control and escalation. Reliable asynchronous reporting often matters more than constant meetings across time zones.
Start with a bounded review
Use a focused assessment or first release to verify working quality, documentation and ownership in practice. Expand the engagement only after the operating relationship is proven.
Apply this to a real system.
Bring the context and we will identify the useful first decision.
Discuss a delivery partnership