What you should own at the end of a software project

The most common way a software project goes wrong is not a bug. It is discovering, a year after launch, that you do not actually own the thing you paid for. The domain is in the agency’s account. The code is on their laptop. The database password is in a departed developer’s head. The only person who can deploy a change has stopped answering.

This is avoidable, and it is avoidable from day one. Here is what you should own at the end of any software project, and what we mean when we say handover is built in.

The code, in your own repository

Every line, in a repository under an account you control, from the first week. Not a copy sent at the end; the live, working repository with its history. If the studio is working from their own organisation, ask them to move it, or to work in yours. There is no good reason to refuse.

You should also be able to build and run it. That means a readme that a competent engineer could follow to get it running on a fresh machine, and a deployment that does not depend on one person’s setup.

The accounts, in your name

Domain registrar, hosting, cloud provider, app store developer accounts, payment gateway, email sending, monitoring, any third-party service the product uses. All in your name, paid for by you, with the studio as a collaborator you can remove. The studio can and should administer them; it should not own them.

The test is simple: if the studio disappeared tomorrow, could you change the password on everything and keep running? If any answer is no, fix it this week.

The data, exportable

Your customers, orders, content and history are yours. You should be able to get them out in a usable form without asking permission. Backups should run automatically, be stored somewhere you control, and be tested by actually restoring one occasionally.

Documentation written for the next person

Not a manual nobody reads. A short, honest set of notes: what the system does, how it is put together, where the sharp edges are, how to deploy, how to find out why something broke. Written for the engineer who arrives after the studio, not for the studio’s own memory.

We write ours as we go, because the alternative is a rushed week at the end that produces something nobody trusts.

The ability to leave

This is the one that matters most and gets discussed least. A good partnership is one you can end. If leaving would be a crisis, you are not a partner; you are a hostage, and every conversation about scope and price is affected by it.

We think being easy to leave is how you keep partners. Most of ours have stayed for years. None of them are staying because they cannot go.

What this looks like in practice

For every project we work on:

• The repository is in the partner’s organisation from the start.
• Every account is in the partner’s name; we are administrators, not owners.
• Backups run to storage the partner controls.
• Documentation is part of the definition of done for each phase, not a task at the end.
• A handover is a conversation, not a project. It can happen at the end of any month.

We write this into proposals because it removes a category of worry, and because we would want the same if we were on the other side of the table.

Questions to ask before you sign

Who owns the repository, and when does it move to us? Which accounts will be in our name? Where do backups go, and who can restore them? What documentation exists at the end of each phase? If we stop in month six, what do we have? The answers should be quick and specific. If they are vague, the vagueness is the answer.

If you are taking over a system where none of this was done, that is common and fixable. It is usually the first thing we do when we take over an existing product: get the ownership right, then get the system right.