You paid to build it — but do you own it? The IP and source-code question that decides whether your custom software is an asset or a leash
Paying for custom software does not make you its owner. In the US and in Egypt alike, the developer keeps the copyright unless a signed assignment says otherwise — and "we host it for you" quietly hands them the keys too. Ownership is a clause, not an invoice.
You approved the quote, paid every invoice, and now a custom CRM runs your business. So you own it — obviously. That instinct is wrong, and it is wrong in a way that stays invisible until the day it matters: the developer wants to walk, or double their rate, or you find the exact same system running at a competitor. This piece is about the gap between paying for software and owning it, and the two or three sentences in a contract that decide which one you actually got.
Start with the rule almost every operator gets backwards. Under US copyright law, the person who writes the code owns it by default — not the person who paid. The "work made for hire" doctrine that would flip that only applies to employees, or to a short list of nine specific work categories that does not include software [1][2]. Hire an outside developer or agency with no written IP assignment, and the copyright stays with them the moment the code is typed, regardless of how much you paid [3]. This is not a loophole; it is the Supreme Court's settled reading of the statute [1].
And this is not an American quirk you can escape by building in Cairo. Egypt's IP law lands in the same place: an employee's work inside their job belongs to the employer, but an independent contractor or agency retains the rights to what they create unless the contract explicitly assigns them [4][5]. Same principle, two markets, one lesson — the paperwork is what transfers ownership, and nothing else does. Here is what the paperwork actually has to say.
The default rule is the whole story, so it is worth stating precisely. In the US, copyright vests in the author — the person who created the work — the instant it is fixed in a tangible form. There is exactly one way that becomes automatically yours instead: the work-made-for-hire rule, which treats the hiring party as the author. But the Supreme Court, in Community for Creative Non-Violence v. Reid, held unanimously that this rule reaches an independent contractor only if the work is one of nine enumerated categories and there is a signed agreement saying so [1]. Software is not on that list [2]. So for the outside developer who builds your CRM, work-made-for-hire simply does not apply — and a contract that just labels the code "work made for hire" does not fix it [3].
Which means, absent a separate written assignment, your developer owns the copyright to the software you paid to build. In practice that is not theoretical. They can reuse the code for another client, license it to a competitor, or refuse to hand over the source when you want to move on — and each of those is within their rights, because they are the owner and you are, at best, a licensee [3]. Paying the invoice bought you permission to use the app. It did not buy you the app.
The fix is unglamorous and absolute: a written, signed copyright assignment transferring the IP to you, ideally with a present-tense "hereby assigns" and a fallback licence in case any right does not transfer cleanly. That one clause is the difference between the two paths in the first figure. It costs nothing to include and everything to omit, and it is the single sentence to check before you sign any build contract — not after, when your leverage is gone and the developer has every reason to charge for what you assumed you already owned.
But copyright is only the top of the stack. Even with the IP assigned, you can still be trapped if you never take delivery of the buildable source code. A running app is a compiled binary; the source is the thing an engineer can actually read, change, and rebuild from. Contracts that promise the "software" but never specify source-code delivery leave you owning a locked box. Where a full handover is genuinely not on the table, the standard mitigation is a source-code escrow: a neutral third party holds the code and releases it to you if the developer goes bankrupt, disappears, or breaches. Note what escrow is and is not — it is conditional access for business continuity, not a transfer of ownership, so it complements an IP assignment rather than replacing it [6].
The third layer is the quiet one, and it is where the "we host it for you" convenience becomes a leash. If your system's domain, cloud account, database, and deployment keys all live under the developer's login, then owning the copyright and holding the source still leaves you unable to move, restart, or even fully see your own system without them. This is the same rented-land trap that a per-seat subscription creates, arriving through the back door of a custom build. Ownership only counts when all three layers — the IP, the source, and the keys — are yours in writing on day one. The healthy default is simple: you commission the work, you get the copyright, you get the source, and the accounts are in your name. Anything short of that, insist on knowing exactly which layer you are giving up and why.
If you are paying to build a system your operation runs on, you take all three layers or you do not sign. Copyright assigned in writing, source code delivered, accounts in your name. Anything less is renting a system you paid to build — the worst of both models. A developer who will not assign the IP to work they were fully paid for is telling you they plan to resell it, and that is the moment to walk, not negotiate.
Most businesses will never touch the source or hire a second developer, so full ownership is a right you pay extra for and never use. A clear, perpetual, transferable licence plus a source-code escrow covers the real risks — the developer vanishing or going under — without the premium that outright IP assignment sometimes carries. Ownership matters for a strategic core system; for a peripheral tool, a well-drafted licence is the pragmatic call.
The honest answer sorts by strategic weight. If the software is your operation — the CRM, the ERP, the platform your revenue flows through — own every layer, because dependence there is existential. If it is a bounded utility you could replace in a weekend, a licence with escrow is fine. The mistake is not choosing a licence; it is choosing one by accident, because nobody read the IP clause before signing.
For anything your business genuinely runs on, own all three layers and put it in writing before the first line is written — the copyright assignment, source-code delivery, and accounts in your name. For a peripheral tool, a transferable licence plus escrow is a defensible, cheaper call. What is never defensible is finding out which one you got after the relationship sours. The clause costs nothing at the start and is priceless at the end. Read it, or have someone read it, before you sign.
- 01For your most critical system, do you actually hold a signed copyright assignment — or have you only ever seen invoices and a working app?
- 02If your current developer disappeared tomorrow, could another engineer take over from the source you already hold, or would you be rebuilding from a locked binary?
- 03Whose name is on the domain, the cloud account, and the deployment keys for the systems your revenue depends on — yours, or your vendor's?
- 04When is full IP ownership worth its premium versus a perpetual licence plus escrow — and how do you decide that per system rather than by reflex?
- 05For a build spanning both US and Egyptian entities, which jurisdiction's assignment governs, and is the clause enforceable in both?
- [1]Community for Creative Non-Violence v. Reid, 490 U.S. 730 (1989) — US Supreme Court, unanimous: work made for hire reaches an independent contractor only via the nine enumerated categories with a signed agreement; otherwise the creator, not the hiring party, owns the copyright.
- [2]OutsideGC — "Common Misconceptions about the Work for Hire Doctrine": software is not one of the nine statutory work-for-hire categories, so labelling a contractor's code "work made for hire" does not, by itself, give the client ownership.
- [3]Amundsen Davis — "I Paid for That Software to Be Developed, So Why Don't I Own It?": without a written copyright assignment the developer retains ownership regardless of payment, and may reuse, license, or resell the code.
- [4]Law No. 82 of 2002 on the Protection of Intellectual Property Rights (Egypt) — WIPO Lex: software is protected as a literary work; employee works inside the job vest in the employer, while contractors retain rights absent an explicit contractual assignment.
- [5]ByLaw ME — "Intellectual Property Law in Egypt": under Law 82/2002, freelancers, contractors, and consultants retain rights to what they create unless the contract explicitly assigns the IP to the engaging company.
- [6]Source code escrow — Wikipedia: a tri-party arrangement where a neutral agent holds the source and releases it to the customer on defined triggers (developer bankruptcy, abandonment, breach); it provides conditional access for continuity, not a transfer of ownership.
We build custom systems you own outright — IP assigned, source delivered, keys in your name.
Every Felukaa build ships with the copyright assigned to you, the full source in your hands, and the accounts under your login — no per-seat rent, no locked box, no leash. Fifteen minutes to check whether your current systems are assets or dependencies.
Book a free 15-min consultation