Do not assume that paying for software makes it yours. What you own depends on what your written agreement says, so make it say so. Whatever the wording, six things should be in your organisation's name and under your control from the first day: the source code, your data, the domain name, the hosting account, any app store and payment accounts, and an owner login. This guide is practical advice, not legal advice.
Six things to hold in your own name
| What | Why it matters | How to check |
|---|---|---|
| Source code | Whoever holds it can change the system. Without it you can only keep using what exists. | Ask for access to the code repository, in an account your organisation owns. |
| Your data | It is the most valuable part and the hardest to rebuild. | Ask for a full export, and do one yourself. |
| Domain name | It is your address. If it lapses or is held by someone else, the system vanishes. | Log in to the registrar account yourself. Check the registered owner and the renewal date. |
| Hosting account | It is where the system and the records physically live. | The bill should come to your organisation's email, not the developer's. |
| Store and payment accounts | The app listing, its reviews and your payouts belong to whoever holds these. | They should be opened in the organisation's name, with the developer invited in. |
| An owner login | Someone in the organisation must be able to add and remove every other user, including the developer. | Log in and remove a test user. |
Questions to ask before you sign
- When the final payment is made, do we own the code written for us? Where does the agreement say so?
- Does the system depend on anything we would have to keep paying you, or anyone else, to use?
- In whose name will the domain, hosting and other accounts be opened?
- Will we receive the code, the logins and written notes at handover?
- If we part ways, what do you hand over, and within how many days?
- If you stop trading or become unreachable, how do we get in?
- What happens to our data in your hands when the work ends?
A developer who is uncomfortable with these questions has told you something useful.
Things that are normal, and fine
- Shared building blocks. Every developer reuses general-purpose code and open-source components. You get the right to use them. You do not get to stop the developer using them for others.
- Ownership passing on final payment. It is reasonable that the code becomes yours when it has been paid for, not before.
- The developer keeping access while they maintain the system, as long as you can withdraw it.
Your records about people
If the system holds details about customers, staff or learners, you are responsible for them. According to DLA Piper's country guide, last modified on 20 March 2026, Namibia had not yet enacted a comprehensive data protection law and a draft bill was under consideration. That may have changed. Whatever the law requires where you operate, good practice is the same: collect only what you need, limit who can see it, and be able to export or delete a person's record.
What an ADA Lab scope says
- The code written for you, your data and the accounts are yours once the last stage is paid.
- Accounts are opened in your organisation's name from the start.
- At handover you receive the code, an owner login, a short manual and a list of every monthly charge.
- If you stop partway, you receive everything built in the stages you paid for.
- We delete our working copies of your data at handover.
If you have already lost control
Secure a copy of your data first, then the domain, then the hosting, then the code. What to do this week.