Source-Code Handover Checklist for Indian SMEs: The Acceptance Walkthrough

This article is the operational half of the story. The contractual half, the six clauses to demand in the agreement before work starts, is covered in Code ownership: what to demand in your developer contract. You need both: the clause makes handover a right, this checklist makes it a fact.

Before handover day: what to request in writing

Two weeks before launch, ask for a handover pack containing:

1. Repository access, granted to an account your company owns.
2. A README covering local setup in plain steps.
3. A deployment guide naming the server, the process and the steps.
4. Database schema documentation.
5. A list of every third-party service, what it does and who owns its account.
6. Licence details for every dependency that carries one.
7. Environment variables and keys list, described by purpose.
8. A known-issues list, however short.

If any item is refused as "internal", treat that as a finding now rather than a crisis later.

Test 1: The repository test

The test. Log in to the repository as yourself, from your own account, and clone the project to a fresh folder on your own machine.

Pass condition. The clone succeeds, contains the current live version, and the commit history is intact rather than a single "final" commit.

Evidence to keep. A screenshot of your access screen showing your company as the owner, plus the date. If the repository lives inside the developer's personal account or organisation with you as a guest, you have access but not ownership, and those are different things.

Test 2: The rebuild test

The test. Following only the README, ask someone technical but new to the project, an in-house person, a freelancer or a niece studying computer science, to get the application running on a local machine or a spare laptop.

Pass condition. The app runs using the README and nothing else. Every question they have to ask is a gap in the documentation worth fixing while the developer is still engaged.

Why it matters. Documentation that only makes sense to its author is not documentation. The rebuild test is the cheapest way to find that out.

Test 3: The credentials test

The test. Open every account the project depends on and confirm the owner is your company: domain registrar, hosting or cloud provider, database, payment gateway, email or SMS provider, analytics, app store accounts.

Pass condition. Each account either belongs to your company email with you holding the login, or has a documented, dated plan to transfer it. No critical account sits in a personal inbox of any individual, including yours.

Evidence to keep. A one-page account inventory: service, purpose, owner, who holds the password, renewal date. This page becomes one of the most valuable documents your company owns.

Test 4: The redeploy test

The test. Using the deployment guide, deploy the application to a staging or spare environment without the developer driving.

Pass condition. The deployment completes from the guide alone. Note any step that needed tribal knowledge, and have it added to the guide in writing that week.

This is the single test most handovers skip, and the one that most reliably predicts whether you can ever change vendors.

Test 5: The restore test

The test. Ask for a demonstration of restoring yesterday's backup onto a clean location. Watch it happen.

Pass condition. A restore completes, the data is readable, and the steps are written down. Confirm the backup schedule: how often, retained for how long, stored where, and who receives failure alerts.

A backup that has never been restored is a hope, not a backup. Companies discover untested backups at the moment they need them, which is the most expensive possible curriculum.

Test 6: The licence test

The test. Review the dependency and licence list against the actual project.

Pass condition. Every library and service in use is identified, with its licence type noted and any commercial licence or subscription named with its renewal cost. Flag anything copyleft if your legal position requires it, and anything trial-licensed that will expire.

Evidence to keep. The licence list appended to the handover pack. Renewal dates should go into your account inventory from Test 3.

Test 7: The exit-support test

The test. Read the support terms aloud and check what they actually promise after handover: how many days of bug-fix support, response expectations, and what happens if you move to a new developer.

Pass condition. The terms are written, dated and specific, not a verbal assurance of "we will always help". A knowledge-transfer window, where the developer answers questions from your next engineer, is worth more than a longer free-support period.

The handover-day scorecard

Test	Pass means	Action if it fails
Repository	You own the repo, history intact	Transfer ownership before final payment
Rebuild	README gets a newcomer running	Developer fills the gaps in writing
Credentials	Company owns every account	Transfer or get a dated plan
Redeploy	Guide alone is sufficient	Document the missing steps
Restore	Backup restore demonstrated	Schedule a witnessed restore
Licence	Dependencies and costs listed	Complete the list; diarise renewals
Exit support	Written, specific terms	Negotiate before the relationship cools

Two failures is a conversation. Four is a renegotiation. Do not release the final milestone while the repository or credentials tests fail, because leverage disappears with the payment.

Red flags on handover day

• "We will send the code after final payment." The code should already be in your repository.
• A zip file instead of repository access. Files without history and issue context are not a handover.
• Shared logins instead of your own accounts.
• Documentation that consists of chat messages.
• No known-issues list, which usually means the list exists but is unwritten.
• Hosting that only the developer can access, billed through them, with no exit path.

Common mistakes

• Running the tests after the final payment. Order matters more than thoroughness.
• Testing with the developer at the keyboard. They must hand you the wheel.
• Accepting "it is all on our internal system" for anything customer-facing.
• Forgetting app store and domain renewals, which expire silently and at the worst time.
• Never re-testing. Repeat the restore test at least once a year.

Frequently asked questions

Should the repository be in my account from day one or at handover?

Day one is safer and is what good agencies offer. If it must wait, the handover day is the last acceptable moment, and Test 1 is where you confirm it.

What if I am not technical enough to run these tests?

Hire an independent technical reviewer for two hours. That fee is small against the cost of a project you cannot ever move away from.

Is a zip file of code ever acceptable?

As an archive, yes. As the handover, no. You also need history, issues, environment descriptions and the ability to receive updates.

How long should exit support last?

Common practice in India runs from 30 to 90 days of included bug-fix support. Big Helpers includes 30 to 90 days of free post-launch support, and hands over repository, hosting and documentation at launch, as stated on the pricing page.

What if my developer has already left?

Start with Tests 3 and 4: recover accounts you can prove ownership of, then have a new engineer attempt a redeploy. Reconstruct what you can and treat the gaps as the brief for the next phase.

Does this apply to no-code and website-builder projects?

In modified form, yes. You still need admin ownership, export capability, a content backup and a written note of what is locked into the platform.

Your next step

Send this checklist to your developer today, whatever stage your project is at, and agree that the seven tests form part of final acceptance. If you are starting a project and want this practice built in from the beginning, Big Helpers works this way by default: weekly demos on a staging URL, written scope with a fixed INR range, and a documented handover as described in how we work. You can raise questions about an existing project on the contact page.