What You Should Actually Receive When a Software Project Ends

A software project is delivered. It works. Everyone is satisfied. Two years later the original developer is unreachable, something breaks, and the business discovers that what it actually received was a working system and nothing else — no documentation, no credentials list, no understanding of how anything fits together.

What you receive at handover determines whether your software is an asset you own or a dependency you rent.

The Handover Checklist

These are what a business should receive when a project completes. Not one of them is unreasonable, and most businesses receive fewer than half.

1. Complete source code

All of it, in a repository in your account — not the developer's. If it's on their GitHub or Bitbucket under their login, you don't have it, you have access to it, and access can be revoked.

2. Every credential, in your name

Domain registrar login. Hosting account. Database credentials. Payment gateway account. Cloud services. App store accounts. Email service. Analytics. Every third-party service the system uses.

The rule: accounts are created in your business's name and the developer is given access — never the reverse. This single practice prevents the majority of situations we're called in to untangle.

3. A written description of what was built

Not technical documentation for engineers. A plain-language document covering what the system does, what the main components are, what external services it depends on, and where things live. Two or three pages is enough, and it's what lets another team understand your system without weeks of investigation.

4. Setup and deployment instructions

How to get the system running on a new server, and how updates are deployed. This sounds technical and it matters commercially: without it, moving hosting or changing developers becomes an expensive discovery exercise.

5. Database structure

What data is stored and how it's organised. Any competent team taking over will need this immediately.

6. User documentation

How your staff actually use it. Even a few pages with screenshots. This becomes invaluable when you hire someone new eighteen months later and nobody remembers how a rarely-used function works.

7. Known issues and deferred items

What isn't finished, what was postponed, and any known limitations. Honest developers provide this; it saves you from discovering the same things through failure.

Why Businesses Don't Get This

Rarely dishonesty. Usually momentum — the project is finished, everyone moves on, and documentation is the item that quietly gets skipped because it produces nothing visible.

Which is exactly why it has to be a contractual deliverable rather than a good intention. Make final payment conditional on handover. Not as distrust — as the normal structure that ensures the last ten percent of work actually happens.

The Ownership Question, Stated Plainly

Your contract should state that the delivered work belongs to you, with ownership transferring on full payment.

One carve-out is legitimate and worth understanding: a development company's pre-existing tools, libraries, and reusable components. If a firm has built internal components it uses across clients, it will license those to you rather than transfer ownership — otherwise it would be signing away its own toolkit with every project.

That's reasonable. What isn't reasonable is vagueness about which parts are which. Ask for it to be specified.

The Test Nobody Runs

Here's how to find out whether your handover was real:

Ask a different developer to review what you have and tell you whether they could take over.

A few hours of someone independent looking at your repository, credentials, and documentation. They'll tell you quickly whether you own a system or a dependency.

Do this while your relationship with the original developer is good — not after it has ended, when gaps become negotiations.

If You've Already Lost Access

A common situation, and partly recoverable.

Domain: registrars have processes for ownership disputes and transfers. This is the most urgent item, because losing a domain is losing your business identity.

Hosting: if the account is in the developer's name, you may need to migrate rather than recover. Get whatever copies of files and databases you can while access exists.

Source code: if you have no copy and no repository access, you may be facing a rebuild. Before assuming that, have someone check what can be recovered from the running system.

Third-party accounts: most providers will help a business recover an account it can prove it owns, with documentation.

The lesson applies to your next project regardless: establish ownership at the start, when it costs an email.

Ongoing Handover, Not Just Final

Handover shouldn't be a single event at the end. Documentation maintained during development is accurate; documentation produced during the final week is a summary written from memory.

Ask for the repository from day one, credentials as accounts are created, and documentation updated as the system evolves. It changes nothing about the work and it means the handover is already done when the project completes.

How We Do It

At Jayshree Technosoft LLP, accounts are created in the client's name from the start, code lives in the client's repository, and documentation is part of the deliverable rather than an afterthought.

We work this way partly because it's right and partly because we've been the team called in to take over systems where none of it existed. Those projects cost the client considerably more than proper handover would have — and the original developer usually wasn't malicious, just finished and gone.

Starting a project and want handover terms agreed upfront, or unsure what you actually own from a previous one? Get in touch — the audit is quick and the answer is worth knowing.