Skip to content
All insights

What to demand when a vendor hands over your system

The moment a project ends is the only moment you have leverage. This is the list to work through before the final invoice is paid.

1 min readAdmin

The most expensive situation in business technology is a working system nobody can touch. It happens gradually: the vendor relationship ends, the documentation was never written, and two years later a change that should take a day takes a month of reverse-engineering.

The cure is a handover done while you still hold the final payment.

Code and accounts

  • A repository you own, with full history — not a zip file emailed at the end
  • Domain registrar access in your company’s name, not your vendor’s
  • Hosting, database, and DNS accounts registered to your company email
  • Every third-party account — payment gateway, mail service, analytics — owned by you, with the vendor added as a user rather than the other way round

Documentation that is actually usable

  • A written explanation of how to run the system locally, tested by someone who did not build it
  • Deployment steps, written out — including how to roll back
  • Environment variables listed, with what each one does
  • For infrastructure work: network diagram, IP allocations, and an asset register
  • Credentials delivered into your password manager, not pasted into a chat thread

The test

Hand the documentation to a technical person who has never seen the project, and ask them to get it running. If they cannot, the handover is not finished — regardless of what the contract says.

Good vendors welcome this. It is the clearest proof that the work was done properly. A vendor who resists it is protecting a dependency, and that dependency is yours to pay for later.

  • Process
  • Procurement

Tell us what is not working

A short call, a clear answer on whether we can help, and a written scope if we can. No pitch deck, no pressure.