What your company should own from day one

When a company starts a software project, attention goes to the screens, the features and the launch date. The question of ownership comes up late, and usually at the worst moment: when the developer stops replying, when the contract ends, or when the company wants to hand the work to someone else.

I register the code repository and all accounts in the client company's name from day one. Here I explain why, and share the list I recommend any company review, whether they work with me or with someone else.

The risk when the developer holds the keys

A common situation: a company hires a developer to build a system and a mobile app. To move faster, the developer buys the domain in his own name, opens the server on his own account, and publishes the app from his own app store account. The system works and the client is happy. Then circumstances change. The developer gets busy with other projects, or there's a dispute over a payment, or the company simply decides to work with another team.

At that point the company discovers it doesn't own what it paid for:

• The code sits on the developer's laptop or in his account, and the company has no copy.
• The server is paid for with his card. If he stops paying, the system stops.
• The domain is registered in his name, renewal is in his hands, and the company's email may depend on it.
• The app is published from his store account. Transferring it is often possible, but it needs his cooperation.
• Third-party services such as the payment gateway, messaging and maps run on his accounts and his keys.

This doesn't mean the developer acted in bad faith. Most of the time it was simply the fastest route at the start. But the outcome is the same: the assets your company runs on depend on one person outside it.

And the risk doesn't only come from disputes. A developer can get busy, change jobs, or forget to renew the domain, and the website and email go down on an ordinary day without anyone meaning harm. Accounts in your name protect you from circumstances, not only from people.

The list: what should be in your company's name

The code repository

The code lives in a code repository on an account your company owns. The developer is added as a member with defined permissions, and can be removed whenever you choose. That way you have the latest version of the code, plus a history of changes: who changed what, and when.

Servers and hosting

The hosting account is opened in the company's name, with the company's payment method. The developer gets technical admin access, but the account itself, and the decision to move or close it, stays with you.

Domain and DNS

The domain is your company's address on the internet. Your website and email depend on it, and sometimes your app does too. It's registered in the company's name, in an account you own, with auto-renewal switched on. The DNS settings, which point the domain at your server and email, are managed from that same account.

App store accounts

If you have a mobile app, the developer account in the app stores is opened in the company's name. The app then appears to the public under your company's name, and ratings and updates stay under your control. The developer is added with publishing access only.

Third-party service accounts

Most systems rely on outside services: sending email and text messages, payment gateways, maps, file storage. Each one is an account with its own integration keys and billing. All of them should be in the company's name, the payment gateway first of all, since your money flows through it.

Email and sign-in methods

The email address used to open these accounts should belong to the company. Not the developer's personal email, and not that of a single employee who might leave. Two-factor authentication should be tied to a number or device the company controls.

Documents that explain how it all runs

Owning the accounts is the first step. The second is making sure someone other than the developer can understand how the system works. You should have written documents that answer practical questions:

• Where the system runs, and which accounts and services it depends on.
• How a new update is deployed.
• How backups are taken, and how to restore from them.
• Which settings and keys the system needs, and where they're stored securely.
• What the integrations with other platforms are, and what happens if one of them goes down.

Good documentation means another developer can take over the system without starting from scratch. That's in your interest even if you keep working with the same developer for a long time, because it makes the relationship a choice rather than a dependency.

If ending the relationship with your developer would stop your system, you don't really own the system.

If your system is already running

Some companies read this list while their system has been live for a while, with some accounts not in their name. That can be fixed, and it's best done at a calm moment, not in the middle of a dispute.

Start with an inventory: where the code is, which account the server is on, whose name the domain is in, and which account the app was published from. Then ask the developer to transfer each item to the company's account, one at a time. Most of these services offer an official way to transfer ownership. A professional developer won't take the request as an accusation. It's a normal request from the owner of the system.

How I apply this in my projects

At the start of a project, the company opens the accounts itself, or I help set them up in its name and with its email. Then the company adds me with the access the work requires. After launch, the accounts stay where they are. The support period set in the offer covers any bug that appears, and maintenance after that is optional. If at any point you decide to stop working with me, you remove my access, and the system keeps running as it is.

I work alone, and bring in specialists when a project needs them. That's one more reason the accounts should be yours: who gets access to the system, and when that access ends, is your decision.

Questions for any developer before you sign

Put these questions to any developer or software company, and note each answer as yes or no:

• Will the code live in a repository on an account your company owns from day one?
• Will hosting be opened in the company's name, with its payment method?
• Will the domain and DNS settings sit in an account you own?
• Will the app be published from the company's own app store account?
• Will the payment gateway, email, messaging and maps services be in the company's name?
• Will the accounts use an email address that belongs to the company?
• Will you receive documents explaining how the system runs, deploys and backs up?
• Will the system keep running if you remove the developer's access?

If any answer is "no", ask for it to be changed in the contract before work starts. These things are far easier on day one than after launch.

If it helps, describe how your process runs today and which systems you depend on, and I'll share what's worth reviewing from an ownership point of view.

Related to this articleProcess