NDA for Freelance Developers: What to Watch Before You Sign

You've built your career on reusable code. The auth wrapper you wrote three years ago, the deployment scripts you carry from project to project, the small utility library you maintain on GitHub and pull into every new engagement — this is the accumulated toolkit that lets you deliver faster than a developer starting from scratch. It's also, in the eyes of a broadly written NDA, a liability.

The clause that creates the problem rarely looks threatening. It's a standard IP assignment sentence buried in a confidentiality agreement: "all work product and intellectual property created in connection with the services shall be the sole property of the Company." No mention of your open-source library. No mention of the internal framework you've maintained for years. But if you use those tools during the engagement — and you will, because that's the point of having them — a clause like this can quietly reach backward into code you wrote long before you met this client.

Most clients don't even realize their NDA does this. They copied a template, or their lawyer used boilerplate designed to protect against a full-time employee walking out with proprietary source. They aren't trying to claim your MIT-licensed npm package. But intent doesn't govern a contract dispute — the language does. Here's what to look for and what to request before you sign.

The Pre-Existing Code Problem

Every experienced freelance developer carries a personal toolkit: internal libraries, boilerplate project scaffolding, config helpers, a tested set of utility functions, deployment and CI templates. This is the compounding asset of a freelance career. The more you build, the faster you deliver, the higher your effective rate.

A broadly written IP assignment clause doesn't distinguish between code you write for this engagement and code you bring to it. Language like "all intellectual property created in connection with the services" or "any code developed during the term of this Agreement" can be read to cover pre-existing work the moment you incorporate it into a deliverable.

Here's the concrete scenario. You have a TypeScript utility library you've refined across a dozen projects — form validation, date handling, API error wrappers. You pull it into the client's codebase to accelerate delivery, customizing a few functions for their specific needs. The NDA assigns the client ownership of "all code developed during the engagement." Do they now own your library? Do they own the modifications you made to it? Can you use the same library on your next project without technically breaching this one?

The honest answer is: it depends on how the clause is drafted, how integrated your code became, and which jurisdiction governs the dispute. That ambiguity is the risk. You don't want to discover the answer during a disagreement over a final invoice.

The fix is a pre-existing IP carve-out — a clause that explicitly separates what you brought from what you built for the client:

Pre-existing IP carve-out:

"The IP assignment in this Agreement applies only to works created specifically and exclusively for Company under this Agreement. Developer retains all right, title, and interest in and to: (a) all code, libraries, tools, frameworks, and utilities owned or developed by Developer prior to this Agreement ('Pre-existing Works'); (b) any improvements, modifications, or derivatives of Pre-existing Works; and (c) general programming methods, techniques, and know-how. To the extent any Pre-existing Works are incorporated into deliverables, Developer grants Company a perpetual, non-exclusive, royalty-free license to use them as part of the deliverable, but retains ownership."

That last sentence matters: it gives the client everything they actually need — the right to use and ship the code you delivered — without transferring ownership of tools you'll reuse elsewhere. Most clients accept it because it addresses their real concern (they can keep running their product) without the overreach.

For a deeper breakdown of how these ownership provisions are drafted, see our guide on NDA IP clauses.

Open Source Contributions Under NDA

This is the risk almost no client considers and almost no developer catches until it's a problem.

Say you maintain an open-source project, or you regularly contribute to one. During the engagement, you fix a bug or add a feature to that project — either on your own time, or because the client's use of it surfaced the issue. Under a broad IP assignment clause, who owns that contribution?

If the clause assigns the client "all code developed during the term of this Agreement" without a time-and-scope limitation, your open-source contributions made during that window are arguably captured — even work you did on a weekend, on your own hardware, for a project entirely unrelated to the client. That creates two problems at once. First, you may be unable to contribute the code upstream, because you no longer own it. Second, if you contribute anyway, you may be putting the client in the awkward position of having "their" IP released under an open-source license, which some licenses make irrevocable.

There's a subtler version too. If you contribute a fix to a library because the client's project needed it, a client could argue the contribution was "created in connection with the services" — even though the code lives in a public repository under an open-source license.

The protection is twofold. First, limit the IP assignment to work created for the client's project specifically, not everything you write during a calendar window. Second, add an explicit open-source carve-out:

Open-source carve-out:

"Nothing in this Agreement restricts Developer's right to contribute to open-source projects, provided such contributions do not include Company's Confidential Information or code written specifically for Company's proprietary product. Company acknowledges that Developer may make general improvements to open-source tools used during the engagement and contribute those improvements upstream under the applicable open-source license."

If the client uses open-source software in their stack (they do), this clause protects both of you: it keeps you free to maintain your projects, and it keeps the client clear of accidentally owning code that's already public.

Non-Competes in Tech: How Broad Is Too Broad?

Non-compete clauses are a risk in almost every freelance NDA, but they hit developers with particular force because software skills are horizontal. A backend engineer who works for a fintech company will inevitably apply the same skills to healthcare, logistics, or e-commerce. There is no such thing as a "fintech-only" REST API or a "healthcare-only" database schema. The underlying craft transfers across every sector.

That's why the scope of a non-compete matters more than its existence. Watch for definitions like these:

• "Developer shall not provide services to any technology company for a period of 12 months."
• "Developer shall not work for any business engaged in software as a service (SaaS)."
• "Developer shall not engage with any company in a competitive or adjacent industry."

Read those literally. "Technology companies" and "SaaS" describe roughly half the businesses that hire freelance developers. A clause that prohibits you from working for any technology company isn't a non-compete — it's a temporary ban on your profession. "Adjacent industry" is worse, because it has no fixed boundary; a client can argue almost anything is adjacent after the fact.

The problem compounds with early-stage clients. A startup that hasn't found product-market fit may define "competitive business" broadly and then pivot. You sign with a fintech startup; eighteen months later it's a healthcare-payments company, and suddenly healthcare is a "competitive industry" under a clause you signed before that pivot existed.

What you want is a narrow, time-anchored definition:

"The restriction in this Section applies only to businesses that offer substantially the same product or service to substantially the same customer segment as Company's primary business as of the Effective Date of this Agreement. It does not restrict Developer from providing general software development services to companies in other industries or product categories, nor from using general skills, experience, and know-how gained during the engagement."

The "as of the Effective Date" language locks the definition to what the company actually is when you sign — not what it might become. For a full treatment of enforceability, duration, and geographic scope, read our guide on the NDA non-compete clause.

Side Projects and Personal Apps During Engagement

If you're a working developer, you probably have a side project. A SaaS idea you tinker with on weekends, an app in the App Store, a course, a tool you sell. NDAs with broad IP assignment and time-based scope can put those at risk in a way that surprises people.

The danger clause is one that assigns the client rights to work created during the term rather than work created for the project. Under that framing, the app you build on Saturday morning — on your own laptop, with no connection to the client's business — could technically fall within "intellectual property developed during the term of this Agreement."

Courts in many jurisdictions won't enforce that reading if the side project is genuinely unrelated, built on your own time and equipment, and doesn't use the client's confidential information. But "a court probably wouldn't enforce it" is not the position you want to negotiate from. The cleaner path is to exclude side projects explicitly:

"This Agreement does not apply to any independent work, projects, or products created by Developer (a) on Developer's own time, (b) without use of Company's equipment, resources, or Confidential Information, and (c) that do not relate to Company's actual or demonstrably anticipated business. Such independent work remains the sole property of Developer."

If you have a specific existing side project, name it in a schedule attached to the agreement. Explicitly listing "Project X, currently at [URL]" as pre-existing and excluded removes all ambiguity about whether continued work on it belongs to the client.

GitHub and Portfolio Repositories

Developers build professional reputation differently than most freelancers. Your GitHub profile, your contribution graph, your public repositories, and the code samples you can show a prospective client are your portfolio. A confidentiality clause can quietly foreclose all of it.

Two provisions cause the damage. First, a clause defining "Confidential Information" broadly enough to cover the code you wrote means you can't show any of it publicly — even sanitized snippets, even architecture you designed. Second, a clause covering the "existence of the relationship" can prohibit you from even listing the client on your resume or LinkedIn.

For a developer, being unable to reference a well-known client is a real professional cost. Working for a recognizable engineering org is a credential that signals capability to future clients. And being unable to show any code from a long engagement leaves a visible gap in the public record of your work.

You don't need to publish the client's proprietary source to protect yourself here. You need two narrow carve-outs — one for attribution, one for generalized code samples:

"Notwithstanding the confidentiality obligations herein, Developer may (a) identify Company as a client on Developer's resume, LinkedIn, and professional references, describing the general nature of services performed without disclosing Confidential Information; and (b) reference general technical approaches, architectures, and non-proprietary code patterns for professional and educational purposes, provided no Confidential Information or Company-specific proprietary code is disclosed."

Note what this does not ask for: it doesn't request the right to publish the client's actual repository. It asks only to describe what kind of work you did and to reference general patterns — the things that make up a credible professional profile without exposing anything the client legitimately needs to protect.

Counter-Language Developers Should Ask For

Here's a consolidated reference. Read the specific NDA first and identify which of these clauses are actually present and problematic — you rarely need all five.

1. Pre-existing IP:

"IP assignment applies only to works created specifically for Company. Developer retains ownership of all pre-existing code, libraries, and tools, including modifications, and grants Company a license to use any incorporated into deliverables."

2. Open source:

"Nothing restricts Developer's right to contribute to open-source projects, provided contributions exclude Company's Confidential Information and proprietary code."

3. Non-compete scope:

"Non-compete restrictions apply only to direct competitors of Company's primary business as of the Effective Date and do not restrict general software development in other industries."

4. Side projects:

"Independent work created on Developer's own time and equipment, unrelated to Company's business and without use of Confidential Information, remains Developer's property."

5. Attribution and portfolio:

"Developer may identify Company as a client and reference general technical approaches and non-proprietary patterns without disclosing Confidential Information."

Most of these are modest requests that a reasonable client will grant, because each one separates the client's legitimate concern (protecting their proprietary product and confidential business information) from the overreaching consequence (claiming your reusable toolkit or banning your profession). If a client refuses all of them without discussion, that itself is a signal worth weighing.

FAQ

If I use my own open-source library in a client's project, do they own it now?

They shouldn't, but a broad IP assignment clause can create genuine ambiguity — especially if you modified the library during the engagement. The clean fix is a pre-existing IP carve-out that keeps ownership with you and grants the client a license to use whatever you incorporated into the deliverable. Without that language, you're relying on a favorable interpretation of vague terms, which is a weak position in a dispute.

Can an NDA really stop me from contributing to open source?

A broadly drafted one can, if it assigns the client all code you write during the contract term regardless of what it's for. That's almost never the client's intent, but the language governs, not the intent. Add an explicit open-source carve-out and limit the IP assignment to work created specifically for the client's project. Both protect you, and both protect the client from accidentally owning code that's released under an irrevocable open-source license.

Is a non-compete that covers all "technology companies" enforceable?

Enforceability varies by jurisdiction — some regions void overbroad non-competes entirely, others narrow them to what's "reasonable," and a few enforce them close to as written. But you shouldn't sign a clause you're betting a court will refuse to enforce. Negotiate the scope down to direct competitors of the client's actual business as of the signing date. That's a defensible position regardless of jurisdiction, and it removes the uncertainty entirely.

What happens to a side project I build during the engagement?

If it's genuinely built on your own time and equipment, unrelated to the client's business, and free of their confidential information, most jurisdictions won't let a client claim it — but a time-based IP clause creates risk you don't need to carry. Exclude independent work explicitly, and if you have a specific existing project, name it in a schedule attached to the agreement so there's no argument later.

Can I show code samples from a past client to land new work?

Only if you're not disclosing confidential or proprietary code. The safe approach is to negotiate a carve-out that lets you reference general technical approaches and non-proprietary patterns, and to identify the client on your resume without revealing specifics. Never publish a client's actual repository or proprietary implementation based on an assumption that it's fine — get the permission in writing, or keep the sample generic.

---

Before signing your next development NDA, get a clause-by-clause risk score in 60 seconds. Upload it to NDA Guard and know exactly which clauses to push back on — or learn more about our NDA review for freelancers.