You have decided to have software built for your business rather than buy a package. What you want at the end is not just a system that works on the day it is delivered. You want a system you control: one you can keep running, change, move to another developer or another server, and sell with the business if it comes to that. Whether you get that is decided mostly by the contract and by what you insist on receiving along the way, not by the code.
This article is the list of what to secure, why each item matters, and how to check you actually have it. If you have not yet decided whether to build, how to decide between Odoo and a custom system comes first; for choosing who builds it, see how to choose a software company; and for the budget, what a custom system costs.
Who owns the code is a question of contract, not payment
Many business owners assume that paying for software means owning it. Legally, that is often not how it works. Computer programs are protected by copyright, and in general the rights in a work start with whoever created it. In Egypt, the Law on the Protection of Intellectual Property Rights, Law No. 82 of 2002 as amended, protects computer programs as works. Paying for the development does not by itself move those rights to you; as WIPO puts it in its guidance on software development agreements, the developer keeps ownership of the IP unless the agreement assigns it to the client.
There are two broad ways a contract can do that:
- Assignment. The developer transfers the economic rights in the code written for you. You own it, and can change it, use it and give it to anyone.
- Licence. The developer keeps ownership and grants you the right to use the system, on terms. That can be perfectly reasonable — many companies reuse their own components across clients — but you need to know the terms: can you modify it, can someone else modify it for you, does the licence survive if you stop paying for support, can it be transferred if you sell the business?
A common and fair arrangement is that you own what was written specifically for you, and receive a permanent licence to the developer's reusable components inside it. Whatever the arrangement, it should be written down in plain language. Have the contract reviewed by a lawyer; this article can tell you what to ask for, not how your contract will be interpreted.
What you should receive, and when
Ownership on paper means little if you cannot actually use what you own. Ask for these to be delivered during the project, not promised for the end.
- The source code, in a repository you control. Access to the code repository from the start, under an account belonging to your company, updated as the work goes on. Code delivered once, on a disk, at the end, is already out of date.
- Build and deployment instructions. How to turn the code into a running system on a fresh server. Without this, having the code is like having a recipe with no method.
- The database structure and how to back it up and restore it.
- A list of every third-party component — libraries, frameworks, paid services — with its licence and any cost.
- Every password and key, handed over and changed from the developer's defaults: servers, database, email service, payment gateway, maps, SMS, app stores.
- Documentation of how the system is organised and how its main parts work, written for the next developer, not for marketing.
Accounts in your company's name
A surprising amount of control lives outside the code, in accounts that someone has to register.
- The domain name. Registered to your company, with you holding the login.
- Servers or cloud hosting. In your company's account, even if the developer administers it.
- App store accounts, if there is a mobile app. The Google Play and Apple developer accounts should be yours; moving an app between accounts later is slow and sometimes impossible.
- Email, SMS, payment and map services. Each one tied to your company, billed to you.
If a developer offers to register these in their own name "to make it easier", thank them and decline.
Open-source components and their licences
Almost every modern system is built on open-source components, which is normal and good. Each comes with a licence, and a few licences place conditions on how you distribute the software that uses them. Ask the developer to confirm, in the list of components above, that nothing in the system restricts how you intend to use or sell it.
If the developer keeps the code: escrow
Sometimes a developer will only license a system and will not hand over the source code — for example, when the system is largely their own product. In that case, a source code escrow arrangement can protect you: the code is deposited with an independent third party and released to you if agreed events happen, such as the developer going out of business or stopping support. It is worth considering when a system is critical to your operations and you cannot get the code any other way.
Security written into the requirements
"Secure" is not a requirement anyone can test. Ask instead for the system to be built and tested against a published standard. The OWASP Application Security Verification Standard, from the Open Worldwide Application Security Project, is a widely used list of security requirements for web applications, organised by level; the OWASP Top 10 is the shorter list of the most critical risks. Naming an ASVS level in the contract gives both sides something concrete to check. At minimum, ask how passwords are stored, how access is controlled, how data is backed up, and how the system is kept updated.
The test that proves you are in control
Before the final payment, ask a developer who did not build the system — a freelancer for a day is enough — to take the repository and the instructions and bring the system up on a clean server. If they can, you are in control. If they cannot, you have found out what is missing while the original developer still has a reason to fix it.
After delivery
- Warranty. A period after delivery during which defects are fixed at no charge. Agree what counts as a defect.
- Support and changes. How requests are made, how fast they are answered, and how changes are priced.
- Hosting and administration. Who keeps the servers updated and the backups running, and what happens if that arrangement ends.
- Handover on exit. What the developer will do, and at what cost, if you move the system to someone else.
A checklist for the contract
- Who owns the code written for us, and what licence we hold for everything else.
- Repository access from the start, in our company's account.
- Build and deployment instructions, database structure, backup and restore procedure.
- A list of all third-party components with their licences and costs.
- All passwords and keys handed over and changed.
- Domain, hosting, app store and service accounts in our company's name.
- Security requirements tied to a named standard and level.
- Escrow, if we will not receive the source code.
- A warranty period and a definition of a defect.
- Support terms and how changes are priced.
- What the developer does if we move the system elsewhere.
The next step
Take this checklist to every company you are considering and ask how they handle each line. The answers will tell you as much about the company as its portfolio does. It is the same list we would expect to be asked ourselves; if you want to discuss a system for your business, start here.
Sources
- Law No. 82 of 2002 on the Protection of Intellectual Property Rights — WIPO Lex. Egypt's intellectual property law, as amended; Arabic text.
- How to secure IP ownership with a software development agreement — World Intellectual Property Organization. Assignment, licensing and joint ownership of commissioned software.
- What is source code escrow? — Escode (NCC Group).
- OWASP Application Security Verification Standard and OWASP Top 10 — OWASP Foundation.