You paid for the software. You may not own it.

If your developer disappeared tomorrow, what your business owns is what the contract says and what you can still log in to. Those are two different lists. Most businesses running custom software have never written down either one, which is how a company that paid for a system discovers it controls none of it.

This is not a rare story and it is not a story about bad developers. It is what happens when a working arrangement built on trust in 2019 is still running the business in 2026 and nobody has looked at the paperwork since.

Why this surfaces now, and who writes about it

Two South African legal commentaries landed in the same week. In one, published on 19 August, Sara-Jane Pluke asks who really owns the copyright to your code. It opens on the observation that software is the core asset of most technology businesses, powering the product and sitting at the centre of any meaningful valuation. The other covers intellectual property assignment in business acquisitions, and is written for the buyer working out which assets are needed to run the business after the deal.

Both are worth reading and neither is written for you. The first addresses software companies, where the code is the product. The second addresses acquirers doing due diligence on somebody else.

The forty-person engineering firm in Pinetown with one custom job-card app is in neither audience. It is not selling and it is not a software business. It is simply a company whose daily operations depend on something it may not own, and nobody in the market has any commercial reason to raise that with it.

What the Copyright Act actually says

The default runs the opposite way to most people's intuition, which is why it is worth knowing before the conversation with the lawyer rather than after it.

Under the Copyright Act 98 of 1978, copyright vests in the author. For a computer program the Act defines the author as the person who exercised control over the making of the program, which is not necessarily the person who typed the code. Section 21(1)(c) does hand ownership of some commissioned works to whoever paid for them, but it is a closed list covering photographs, portraits, gravures, films and sound recordings. Computer programs are not on it.

Software written by an employee in the course of employment belongs to the employer under section 21(1)(d). Software commissioned from an independent contractor does not automatically belong to you, and an assignment is not valid unless it is in writing and signed by the assignor, under section 22(3). Paying an invoice is not an assignment.

Where there is no written assignment, what a business usually holds is an implied licence to use the software. That is a weaker thing than ownership, and it may not extend to modifying the code or handing it to a different developer. Whether a particular arrangement passes the control test is fact by fact, and it is a question for someone who reads your contract.

The list you can check yourself

Control you can audit this week, for free, and it is usually the more urgent of the two questions.

Work through it in the order a lock-out actually happens:

• Source code. Where does it live? If the answer is a repository under the developer's personal account, you have access at their discretion.
• The server. Whose name is on the hosting account, and whose card pays it?
• The domain. Who is the registrant, not the technical contact?
• The database. Can anyone other than the developer produce a full export?
• Third-party keys. Payment gateway, SMS provider, mapping, email. Accounts opened in a contractor's name do not transfer when the relationship ends.
• The build. If the code exists but nobody can deploy it, you own a document rather than a system.

A business can fail every one of those and still be the rightful owner of the copyright. It will also be unable to change a single line without a phone call to someone who no longer answers it.

What it costs when it goes wrong

The bill is rarely a legal one. It is a rebuild.

A custom system that cannot be modified stops matching the business within about two years, because businesses change and unmaintained software does not. At that point the options are to work around it manually, which quietly adds staff, or to rewrite it, which means paying twice for something you already bought.

The second cost is worse and less visible. A system nobody can safely touch becomes a system nobody dares connect to anything else. The accounting package cannot read from it. The reporting sits in exports done by hand. Every improvement elsewhere in the business routes around it, and it turns into the reason nothing joins up.

The clause that would have prevented it

For work commissioned from here on, the contract needs to say four things plainly, and none of them are unusual asks:

• All intellectual property in work produced under the agreement is assigned to the business, in writing and signed
• The business is named as the account holder for the repository, the hosting, the domain and every third-party service
• The developer supplies the source code and deployment instructions in a form the business holds independently of them
• Anything based on the developer's pre-existing components is licensed to the business in terms stated in the contract

That last one matters more than people expect. A developer who reuses their own framework across clients may be entirely entitled to do so, and you still need to know what you have been given and on what terms.

This is the thing we run into every single time. Connecting the systems a business already pays for means asking who controls each one. On most engagements at least one answer is a contractor who left years ago with no written assignment and no handover. Zorah's discovery audit exists partly because that question has to be answered before any integration work can honestly be scoped.

What to do on Monday

Do not start with the lawyer. Start with the login.

Open your custom system's hosting account and look at the registered email address. If it is not one your business controls, that is your first task and it is usually a support ticket rather than a negotiation. Do the same for the domain registration.

Then send one email to whoever maintains the software asking for a copy of the source code and a written note of how it gets deployed. The request is ordinary and reasonable. How long it takes to be answered will tell you most of what you need to know about your position, and the answer costs nothing to find out while the relationship is still good.