How to Protect Intellectual Property (IP) When Hiring Dev Agencies

When outsourcing custom software or SaaS development, one question keeps founders up at night:

"Who actually owns the code?"

Without clear legal agreements and operational discipline, you could discover that your agency retains ownership of core algorithms, blocking future investor due diligence or company acquisitions.

Here is how to ensure 100% intellectual property protection.

This is a legal-adjacent topic and we are engineers, not lawyers — every clause below should be reviewed by counsel qualified in your jurisdiction. What follows is the operational and contractual checklist we see working in practice, and the failures that show up later in due diligence.

What "IP" Actually Covers

Founders usually mean "the code", but diligence asks about much more:

And what is usually not yours: the agency's pre-existing libraries and internal frameworks, generic industry know-how, and third-party open-source components (which are licensed, not owned, by anyone).

The clean way to handle that distinction is a clause separating background IP (things the vendor brought) from foreground IP (things created for you). You want the foreground assigned outright, and a perpetual, irrevocable, royalty-free licence to any background IP embedded in your deliverable — so nothing you depend on can be pulled out from under you.

3 Essential Contract Clauses

1. Work Made for Hire & Assignment of Rights: Explicitly state that all custom code, UI designs, databases, and assets created under the engagement are assigned immediately and irrevocably to your company upon payment.
2. Comprehensive Mutual NDA: Protect trade secrets, business logic, customer data, and commercial pricing models.
3. Open-Source License Transparency: Require the agency to disclose all open-source libraries used (favoring MIT/BSD/Apache licenses and avoiding restrictive AGPL licenses).

Getting the Assignment Right by Jurisdiction

• United States: contractor work is not automatically "work made for hire" the way employee work is. You need an explicit, written assignment of copyright signed by the contractor — and ideally by the vendor's individual engineers or via a flow-down clause obliging the vendor to bind its staff.
• United Kingdom: copyright assignment must be in writing and signed by the assignor. An unsigned email promising ownership is worth very little.
• Australia: assignment must also be in writing and signed; moral rights require a separate consent to waive.
• Continental Europe: moral rights (droit moral) are often inalienable, so the practical approach is a broad exclusive licence plus a moral rights waiver where permitted. France and Germany treat this differently from the UK.
• Bangladesh and other jurisdictions: assignment language must be explicit in the contract; a bare "vendor will deliver software" clause does not transfer copyright.

The recurring theme: ownership transfers need to be in writing, and often signed. Verbal assurances, a handshake, or a project brief labelled "client owns everything" are the kind of thing that becomes very expensive during an acquisition.

Additional Clauses Worth Insisting On

• Warranty of originality: the vendor confirms the work does not knowingly infringe third-party rights.
• Flow-down obligations: the vendor binds its own employees and subcontractors to the same terms. Without it, a contractor hired by your vendor may hold rights your vendor cannot assign.
• Third-party dependency schedule: an attached list of every library, its licence, and its version, updated at handover.
• No residuals clause: refuse language allowing the vendor to reuse your proprietary techniques freely.
• Escrow or fallback: for critical systems, code escrow or a documented release trigger if the vendor ceases trading.
• Transition assistance: an explicit obligation to help a successor team for a defined period after termination.

The Open-Source Question, Practically

Most open-source licences are fine in commercial software: MIT, BSD, Apache 2.0. The ones that demand attention:

• AGPL — network use of modified code can trigger source-disclosure obligations, which is a serious problem for a SaaS product.
• GPL/LGPL — copyleft obligations depending on how the code is linked or modified.
• "Non-commercial" or custom licences — frequently incompatible with a commercial product.
• Unlicensed code on GitHub — no licence means all rights reserved, so you technically have no permission to use it.

Run automated licence scanning in CI (pip-licenses, license-checker, or a dedicated tool) and require the vendor to keep the dependency list current. Discovering an AGPL component three weeks before an acquisition is a genuinely bad week.

Operational Security Best Practices

• Host on Your Own GitHub / GitLab Organizations: Never allow development in private agency accounts where access can be revoked during disputes.
• Control Cloud Credentials: Maintain administrative ownership of AWS, Stripe, and domain accounts; grant least-privilege IAM credentials to developers.

The principle generalises: you should hold the keys to everything the business depends on. That includes:

Practically, this means creating your organisation, repositories and accounts before work starts, then inviting the vendor in with the minimum access required. It is far easier than extracting ownership later, and it removes the single most common hostage situation in agency relationships.

Technical Measures That Support the Legal Ones

Contracts establish ownership; engineering practices make ownership verifiable. Auditors and acquirers look for evidence, not just clauses:

• Contributor agreements for everyone who commits. A CLA or DCO on each commit, or a flow-down clause with a list of authorised committers, closes the gap where an unnamed subcontractor contributed code.
• Signed commits where feasible, so authorship is attributable.
• Repository-level audit logs retained, showing who accessed what and when.
• A software bill of materials (SBOM) generated automatically at each release, listing every dependency and version — this is increasingly requested in enterprise procurement as well as diligence.
• Licence scanning in CI, failing the build on AGPL or unknown licences rather than discovering them later.
• Secrets management in your own vault, with rotation on any contractor departure.
• Access reviews each quarter, and deprovisioning as an explicit step when an engagement ends.

The combination is greater than the sum of the parts: a contract that assigns the IP, a repository that proves who wrote it, and a pipeline that proves which third-party components are inside it. That trio answers almost every question a technical due diligence review will ask.

The Full Timeline: What to Do When

What Fails in Due Diligence

Investors and acquirers ask a predictable set of questions. The failures we hear about:

• No signed assignment from a contractor or subcontractor who contributed code.
• Missing commit history — a repository initialised with a single "initial commit", which hides provenance and looks like a red flag.
• Unlicensed or AGPL dependencies in a commercial product.
• Accounts in the vendor's name, requiring a painful migration mid-transaction.
• No documentation, making the acquisition harder to value and easier to discount.
• A former contractor's credentials still active, discovered during the security review.
• Unclear separation between your IP and the vendor's reusable frameworks.

Each of those is cheap to prevent at the start and expensive to fix under a deal timeline.

Red Flags to Walk Away From

• The agency insists on hosting the repository in their own account.
• No willingness to sign an IP assignment or bind subcontractors.
• Inability to produce a list of open-source dependencies.
• Unwillingness to let your team or an auditor read the code.
• Vagueness about who owns the infrastructure accounts.
• Refusal to include a handover or transition clause.

Nearly every studio that does good work will sign all of the above without drama — and one that will not is telling you something important about how the relationship will go.

If you take one action from this article, make it this: before the next engagement starts, confirm three things in writing — who owns the code, whose accounts everything lives in, and what you receive at handover. Everything else here is detail around those three sentences, and they take an afternoon to settle while the relationship is friendly. Settling them later, during a dispute or an acquisition, costs orders of magnitude more.

Related reading: How to choose a development company covers the wider due-diligence process; outsourcing without losing control covers operational control; and staff augmentation vs a dedicated team covers the contract model that frames all of it. At KEHEM IT, our client agreements provide 100% intellectual property ownership from Day 1.

Signing with an agency soon? Ask us for the contract clauses to insist on — IP, escrow, and the rest.