You pay a development team $150,000 to build your product. They deliver it. You launch. Six months later you want to hire a different team for a new phase, and your original developer tells you they own the codebase. Or they built it on a proprietary framework that only they can maintain. Or the contract has a clause you did not read that gives them a perpetual license to reuse your code for other clients.
This happens far more often than it should. And it is entirely preventable with the right contract, the right questions, and the right development partner.
IP ownership is one of the least discussed and most consequential aspects of hiring a software development team. In our experience, fewer than half of the founders we talk to have read the IP clause in their existing development contracts. The ones who have read it often do not fully understand what it means.
The Default Rules Are Not in Your Favor
In most jurisdictions, the default intellectual property rules work like this: the person or entity that creates the work owns it. If you hire an independent contractor to write code, they own that code unless your contract explicitly states otherwise. This is different from employment, where work for hire doctrines typically give the employer automatic ownership.
This means if you engage a freelancer or an agency without a proper IP assignment clause, they could legally own the code they wrote for your product. They could reuse it. They could license it to a competitor. They could hold it hostage during a contract dispute.
The fix is straightforward but must be explicit: your contract needs a clear, unconditional assignment of all intellectual property rights for work created during the engagement. Not a license. Not shared ownership. Full assignment with no strings attached.
What Your Contract Should Include
A solid IP clause covers more than just "you own the code." Here is what we include in every contract we sign at Veld Systems, and what you should look for in any development agreement:
Full IP assignment. All code, designs, documentation, and related materials created during the engagement are assigned to you upon creation or upon payment. The assignment should be irrevocable and worldwide.
Pre existing IP carve out. Your developer will use libraries, frameworks, and internal tools that existed before your project. These should be clearly identified and excluded from the assignment. You get a perpetual, royalty free license to use any pre existing IP that is embedded in your product, but the developer retains ownership of their prior work. This is normal and fair.
Open source disclosure. Any open source components used in your project should be listed, along with their licenses. You need to know if your product includes GPL licensed code (which has viral licensing requirements) versus MIT or Apache licensed code (which is permissive). A responsible team will provide a full dependency audit.
Moral rights waiver. In some jurisdictions, creators have "moral rights" that are separate from economic rights and cannot be assigned. Your contract should include a waiver of moral rights to the extent permitted by law, or at minimum a commitment not to exercise them.
Source code access. This should be obvious, but we have seen contracts where the client pays for the product but does not receive access to the source code repository. You should have access to the repo from day one, not just at the end of the project.
Red Flags That Should Worry You
Over the years, we have reviewed contracts from other development shops on behalf of clients who came to us after a bad experience. Here are the red flags that come up repeatedly:
"Work for hire" without assignment language. In the United States, the work for hire doctrine has specific requirements. If the relationship does not meet those requirements (which it often does not for independent contractors), calling something "work for hire" does not actually make it one. You need explicit assignment language regardless.
Licenses instead of assignments. Some contracts give you a "license" to use the code rather than transferring ownership. A license can be revoked. It can be non exclusive, meaning the developer can sell the same code to someone else. It can expire. Ownership cannot. Insist on assignment, not licensing.
Proprietary frameworks and lock in. If your developer builds your product on their proprietary framework or internal platform, you are locked in. You cannot move to a different team without rebuilding from scratch. We have written about the difference between choosing Veld versus freelancers, and IP transparency is one of the biggest distinctions.
No mention of IP at all. Believe it or not, some development contracts, especially with offshore teams, say nothing about intellectual property. In that scenario, default law applies, which means the developer almost certainly owns the code. If you are evaluating offshore versus domestic options, IP protection should be at the top of your criteria.
How We Handle IP at Veld Systems
Our position is simple: you pay for it, you own it. Every contract we sign includes full IP assignment of all custom work product. We identify pre existing IP and open source components clearly. We give you access to the code repository from the start.
We do not build on proprietary internal platforms. We use standard, widely supported technologies that any competent team can pick up and maintain. If you ever decide to work with a different team, whether it is an in house hire or another agency, your codebase should be portable and understandable.
This is not charity. It is good business. Teams that trap clients through IP ambiguity or technical lock in are optimizing for retention through dependency, not through quality. We would rather earn ongoing work by being the best option, not the only option.
Protecting Yourself Beyond the Contract
A contract is essential, but it is not the only protection. Here are practical steps you should take regardless of who builds your product:
Own the repository. The code repository should be on your GitHub organization, your GitLab instance, or your Bitbucket account. Not the developer's. If the relationship ends, you should not need to ask anyone for access to your own code.
Own the infrastructure. Your AWS account, your Supabase project, your domain registrations, and your API keys should all be under your company's credentials. We have seen developers host client applications on their own infrastructure and then withhold access during payment disputes.
Document everything. Architecture decisions, deployment processes, environment variables, and third party service configurations should all be documented. If your development team disappeared tomorrow, could someone else pick up where they left off? We cover the architectural side of this in our system architecture service, and documentation is a core deliverable on every project.
Regular code access reviews. At least quarterly, verify that you still have access to all critical systems. Check that you can pull the latest code, access the production database, and deploy independently if needed. Do not wait for a crisis to discover you have been locked out.
What About Internal Developers
If you hire full time employees to write code, the IP situation is generally simpler. Employment agreements typically include IP assignment clauses, and work for hire doctrine applies more cleanly to employer employee relationships.
However, there are still nuances. Employees who work on side projects, contribute to open source, or bring code from previous employers can create IP complications. Your employment agreement should clearly define what constitutes company work versus personal work, and should include a disclosure requirement for pre existing IP.
If you have a mixed team of employees and contractors, make sure every contributor has a signed agreement that addresses IP ownership. One unsigned contractor can create a gap in your IP chain that becomes a problem during due diligence for funding or acquisition.
IP Ownership During Acquisition and Fundraising
This is where IP ownership goes from "important" to "deal critical." During due diligence for an acquisition or a funding round, investors and buyers will examine your IP chain. They will want to see:
- Signed IP assignment agreements from every contributor
- A complete list of open source dependencies and their licenses
- Proof that you own or have rights to all third party assets (fonts, images, icons)
- Clean repository history showing who contributed what
If there is a gap, it can delay or kill a deal. We have seen a $2M acquisition stall for three months because the target company could not produce a signed IP agreement from a freelancer who had written 15% of the codebase two years earlier. The freelancer had moved countries and was unresponsive. The deal eventually closed but at a reduced valuation.
Getting your IP house in order now is infinitely cheaper than trying to fix it under the pressure of a closing timeline. If you are building something that you intend to sell, license, or raise capital on, get in touch with us and we will make sure your IP ownership is airtight from the start.