Paying for software is not the same as owning it
Here is a conversation I have more often than I would like.
A founder comes to us because their old agency went quiet, or a freelancer moved on, or the relationship simply ended badly. They want us to pick up the product. So we ask for the basics: the repository, the hosting account, the domain, the app store listing.
And the answer is some version of "I think the developer has all that."
They paid every invoice. They have the app on their phone. But the code lives in someone else's GitHub, the servers are on someone else's credit card, and the contract never actually said who owns what.
That is not a rare edge case. It is one of the most common and most expensive surprises in early-stage software.
The legal default is probably not what you think
Most founders assume that if they pay for code, they own it. In many places the default rule works the other way for outside contractors.
- United States. Under US copyright law, work created by an employee as part of their job generally belongs to the employer. Work from an independent contractor is different. Software rarely fits the narrow "work made for hire" categories for commissioned work, so ownership usually needs a written assignment signed by the contractor.
- United Kingdom. The Copyright, Designs and Patents Act 1988 gives employers first ownership of work employees create in the course of their job. For freelancers and agencies, copyright generally stays with the creator unless there is a written assignment signed by them.
- UAE. Copyright is governed by Federal Decree-Law No. 38 of 2021, and free zones such as DIFC and ADGM have their own legal frameworks for many commercial matters. The safe move is the same: put ownership in writing, and have local counsel check it fits where your company is set up.
The pattern across all three is simple. Without a clear written assignment, "we paid for it" is a weak position. You may have a license to use the software, but not the right to change it, sell it, or hand it to a new team without a fight.
The four layers of ownership
Owning your product is not just a clause in a contract. It has four layers, and you need all of them.
If any one layer is missing, you are not fully in control. A perfect contract does not help if the only copy of the code sits in a freelancer's private repo. And having the repo does not help if nobody can deploy it.
The founder checklist
Run through this before you sign, and check it again at every major milestone.
1. The contract
- A clause that assigns all IP to your company, not just a license to use it
- Assignment happens as the work is created or on payment, written clearly, with no ownership held back until a final milestone that may never arrive
- Any subcontractors the agency uses are bound by the same assignment
- The agency's own reusable tools or libraries are listed, with a permanent license for you to keep using them
- A clear handover obligation if the relationship ends
2. The code
- Repositories live in a GitHub, GitLab, or Bitbucket organization you own, with you as an owner or admin
- Developers are added as members, not the other way around
- Every commit is pushed there, not to a personal account that gets synced "later"
- You can clone and build the project without asking anyone for permission
3. The infrastructure
- AWS, Azure, Google Cloud, or VPS accounts are registered to your company and billed to your card
- The domain is registered in your company name, at a registrar you can log into
- Apple App Store and Google Play developer accounts belong to your company
- Email services, payment gateways like Stripe, analytics, and error tracking are under your accounts, with the team invited as users
4. The knowledge
- Secrets and API keys live in a password manager or secrets vault you control
- A short README explains how to run, build, and deploy the project
- Architecture notes cover the main services and how data moves between them
- There is a written list of every third-party service and what it costs each month
The open source question nobody asks
Almost every modern app is built on open source libraries. That is normal and good. It also means "we own all the code" is never literally true, and the licenses on those libraries matter.
In Black Duck's 2025 Open Source Security and Risk Analysis, 97% of audited codebases contained open source, 56% had license conflicts, and a third included code with no license or custom terms. Black Duck also found that nearly 30% of those conflicts came from transitive dependencies, the libraries your libraries pull in.
Why a founder should care:
- Permissive licenses like MIT and Apache 2.0 are usually easy to live with in commercial products.
- Copyleft licenses like GPL and AGPL can require you to share your own source code under certain conditions. AGPL can apply even when you only run the software as a web service.
- Unlicensed code copied from a forum or a random repo technically gives you no right to use it at all.
This comes up hard during fundraising and acquisitions. Investors and buyers run code scans as part of due diligence, and license surprises can delay or reprice a deal.
Ask your team for a software bill of materials (SBOM) or a simple license report. Most modern tooling can generate one in minutes.
What about AI-written code?
Many teams, including ours, use AI coding tools to move faster. That raises a fair question: who owns code an AI helped write?
The honest answer is that the law is still catching up. The US Copyright Office has said that purely AI-generated material without meaningful human authorship is not protected by copyright, while work where humans make the creative decisions can be. The UK and UAE are working through similar questions.
What this means in practice:
- Make sure senior engineers are designing, reviewing, and shaping the code, not just pasting output
- Keep your contract's IP assignment broad enough to cover all work delivered, however it was produced
- Check the terms of the AI tools your team uses, especially around your data and code being used for training
AI makes us faster. It does not change who the product belongs to. If you paid for it, the code, the repos, and the accounts should all have your name on them from the first commit.
Red flags when hiring a dev team
Walk away, or at least slow down, if you hear any of these:
- "We will transfer the code once the project is finished and fully paid."
- "It is easier if we host it on our account for now."
- "Our framework is proprietary, so you license it from us."
- "You do not need access to the repo, we will send you updates."
- "We do not really do documentation, but we are always available."
None of these automatically mean bad intent. Plenty of agencies work this way out of habit. But each one shifts leverage away from you, and you will feel it the day you want to change teams.
How we handle ownership at Fionetix
We built Fionetix around a simple rule: you own 100% of the code, repositories, and IP from the moment it is written. Not at the end of the project. Not after the final invoice. From day one.
In practice that means:
- Code goes into your organization's repos from the first commit
- Cloud, domains, and third-party services sit in your accounts, with us invited as users
- Every project ends with a documented, working handover
- Monthly maintenance can be paused or cancelled anytime, so you are never locked in
If you are starting a new build, our Custom Software package delivers a production-ready app in about a month for $1,999. If you already have a product and are not sure where you stand, an hour of consultancy at $30 is often enough to audit your repos, accounts, and contracts and tell you exactly what to fix.
Own it before you need it
Ownership problems are invisible right up until the moment they are not. That moment is usually the worst possible time: a falling out, a funding round, an acquisition, or an outage at 2 AM with nobody to call.
Spend an afternoon on this checklist now. Move the repos into your organization. Put the accounts in your company's name. Get the assignment in writing. It is the cheapest insurance you will ever buy for your product.
