Handing over code, credentials and documentation

The situation

A chain of dental clinics in Ahmedabad has a new booking system. Patients book on WhatsApp, the front desk sees the day's appointments on a tablet, and each clinic gets a daily summary. The system works, the last increment has been accepted, and the owner is relieved.

Then a simple question comes up. A cousin who works in IT asks, "Who has the password to the server?" Nobody at the clinic knows. The domain was bought on someone's personal card. The WhatsApp Business account sits under an email address that belongs to the old developer. The code lives somewhere, but the clinic has never seen it.

This happens far more often than it should, in India and abroad. A system you paid for is only fully yours when you can run it, change it and move it without asking anyone's permission. That is what a proper handover gives you.

What you should own

Under 2good terms, the source code, documentation and intellectual property belong to the client on acceptance and payment, and this is written into the Statement of Work. Read that clause before you sign, so you know exactly what transfers and when. If anything is unusual, such as code licensed from elsewhere, ask your lawyer to check the wording.

Ownership on paper is the first half. The second half is practical: the accounts, keys and documents that let you use what you own.

What a proper handover contains

Repository access

The source code should sit in a repository, on GitHub, GitLab or Bitbucket, under an organisation account that you control. You should be an owner of that organisation, with the team added as members who can later be removed. Check that the repository holds the full history, all branches that matter, and the files needed to build the system from scratch.

Credentials and secrets

Every system depends on secrets: database passwords, API keys for the payment gateway or SMS provider, signing keys for mobile apps, tokens for WhatsApp. These should be stored in a password manager or a secrets store that you control, with a list of what each one is for. Secrets should never sit inside the code itself. After handover, it is good practice to rotate the important ones, so that only your people hold the current values.

Cloud accounts in your name

Hosting on AWS, Google Cloud, Azure or a smaller provider should be in an account registered to your business, paid with your card or invoiced to you. The team works inside it with their own logins, which you can remove at any time. If the system was set up in the team's account during the build, moving it to yours should be part of the plan and written into the Statement of Work. Who pays for hosting and other third party services is agreed in writing before work starts.

Domain and DNS

The domain, for example the clinic's .in or .com address, should be registered in your business name, with your email as the contact, at a registrar where you hold the login. The same goes for DNS settings and SSL certificates. A domain that lapses or sits in someone else's account can take your whole service offline.

App store accounts

If there is a mobile app, publish it under your own Apple App Store and Google Play developer accounts. Moving an app between accounts later is slow. The team can be invited to your accounts to upload builds, and removed when the work ends.

Third party services

List every outside service the system uses: payment gateway, SMS or WhatsApp provider, email sending, maps, analytics, AI APIs. For each one, note whose account it is, who pays, and where the login is kept. For a WhatsApp booking system, the WhatsApp Business account and the phone number linked to it matter a great deal. Make sure both are registered to your business.

Documentation

Good documentation lets a new developer, from any company, pick up the system without guessing. At a minimum it should explain:

• What the system does and the main parts it is made of.
• How to set up a development copy on a laptop.
• How to build, test and deploy a new version.
• Where data is stored and how backups work.
• Which outside services are used, and why.
• Known limits and decisions taken along the way.

A delivery note for each block

At 2good, documentation and a delivery note come with each block of work. The delivery note records what was built, what was accepted, the hours used against scope, and anything left open. Keep these together. In time they become the history of your system and help anyone who joins later.

A runbook

A runbook is a short practical document for the moments when something goes wrong or needs routine care. For the clinic system it might cover: how to restart the service, what to do if WhatsApp messages stop arriving, how to restore yesterday's backup, how to add a new clinic branch, and who to call. Write it so that a reasonably technical person who has never seen the system can follow it at nine in the evening.

How to run the handover

Treat the handover as an increment with its own acceptance list. Ask for a call where the team walks you through each item, and do the checks yourself while they watch:

• Log in to the repository, cloud account, domain registrar and app stores with your own credentials.
• Ask someone outside the team, perhaps a freelance developer or your IT cousin, to set up a copy of the system from the documentation alone.
• Restore a backup to a test environment.
• Remove one team member's access and confirm that nothing breaks.

If something fails, it is logged and put right, the same as any other gap against the specification.

What a handover cannot do

A handover cannot transfer knowledge that was never written down. If decisions were made on calls and not recorded, they are lost when the team moves on. Ask for documentation throughout the build, a little with each block, and save the scramble at the end.

Ownership also brings responsibility. Once the accounts are in your name, renewals, bills and security updates are yours to watch. If you would like the team to carry on with maintenance, that can be agreed as further work on the same terms.

A handover checklist

Before you treat a project as handed over, check that:

• The Statement of Work says the source code, documentation and IP belong to you on acceptance and payment.
• The code is in a repository under an organisation you own, with full history.
• Every secret is listed, stored where you control it, and the important ones have been rotated.
• Cloud hosting is in an account registered and paid for by your business.
• The domain, DNS and certificates are in your name, under your login.
• Mobile apps are published under your own developer accounts.
• Every third party service is listed with its owner, payer and login location.
• Documentation explains setup, deployment, data, backups and known limits.
• You have a delivery note for every block.
• A runbook covers restarts, backups, common failures and routine tasks.
• Someone outside the team has set up the system from the documentation.
• You can remove the team's access without anything breaking.

For how acceptance and payment fit together before handover, see pay after acceptance, and for what each block includes, see pricing.