Who owns the code depends on what your contract says, not on who paid for the work. Do not assume that paying the invoice settles it. If the agreement is silent or vague, find out where you stand before you rely on the software. That is a question for a lawyer reading your actual contract, and what follows is what to look for and what to ask.
What to look for in the contract
- An assignment of rights. Wording that transfers ownership of the work to you, as opposed to granting you a licence to use it. Note when the transfer happens: on creation, on delivery, or on final payment.
- What is excluded. A contractor may keep ownership of tools and code written before your project and reused across clients. That can be reasonable, provided you get a lasting licence to use those parts inside your system.
- Who else worked on it. If subcontractors or freelancers were used, ask whether their agreements pass rights through to the contractor and so to you.
- What happens if the relationship ends early or there is a payment dispute.
- Whether you may have another developer modify the code.
Access is a separate matter from ownership
An organiser can own every line on paper and still be locked out in practice. Ticket pages, registration forms and volunteer rotas run on accounts, and whoever's name is on the account controls it. Check each of these.
- The code repository. You should have your own administrator access, not a zip file sent once.
- Hosting and the database. Ideally the account is in your organisation's name with the contractor invited in.
- The domain name. Registered to you, with your email as the contact and renewal on your card.
- Accounts for email sending, text messages, maps and payment processing.
- App store listings, if there is a mobile app for attendees.
Use a shared mailbox belonging to the organisation for all of these, not one person's address. Event teams change between editions, and accounts tied to a departed volunteer are hard to recover.
Third-party components
Custom software is normally built partly from open source libraries and paid services. You will not own those, and that is normal. What you want is a list: which components are used, under what licences, which paid services the system depends on, and who pays for them. Ask your lawyer whether any of the licences place conditions on how you use or share the software.
Ask before the work starts
These conversations are easy at the start and awkward later. Ask the contractor to confirm in writing who will own the finished code, when ownership passes, where the repository will live, in whose name the accounts will be opened, and what you would receive if you parted ways halfway through.
A contractor who intends to hand everything over has no reason to avoid the questions.
Ownership also affects the sums. A system you own and can move has a different long-run cost from one you effectively rent from its builder. If you are comparing either with a registration or ticketing platform's fees, our software bill calculator, a free calculator, gives the yearly and three-year total of what you are billed now.
At Hiro the position is simple: the customer owns the code and the data and can take both whenever they like. Our guide to renting versus owning business software covers data ownership and who maintains the system afterwards, and our page for event organisers describes what can be rebuilt.