Working with vendors and development contractors
What must be in the agreement
Full ownership of the code and the data; the repository in your account from day one; access to environments; and a deliverables list that includes documentation and knowledge transfer, not just running code.
And: what happens at the end — how much handover support, and who holds the keys.
How to track without micromanaging
A demo every two weeks on a real environment, not a presentation. Access to the build pipeline and the metrics. And written acceptance criteria for each milestone — “we're done” isn't a state but an agreement.
Check the skeleton early: deployment, authentication, monitoring. Projects that fall apart at the end almost always fall apart there.
Warning signs
No access to the repository; no tests; “we'll do that at the end” on security and infrastructure topics; and a dependence on one person. Each is worth a conversation immediately, not in a month.
Going deeper
Ask for a short external code review mid-project, not at the end. It's relatively cheap and reveals structural gaps while there's still time to fix them — after handover, every finding becomes a commercial dispute.