Freelancer Contracts and NDA Basics

Most freelance disputes are not caused by bad faith. They are caused by two people who each thought “that was obviously included” about different things, and who never wrote either version down.

A contract, at its most useful, is not a legal weapon. It is a forcing function: the act of writing the terms down is what surfaces the disagreement while it is still cheap. That is why the shortest workable agreement usually beats a long one nobody reads, and why the most valuable clause is often the one that simply says what “finished” means.

A note before you start

This guide is general information about how freelance agreements and NDAs commonly work. It is not legal advice, it is not a substitute for a solicitor or attorney, and nothing here should be treated as a statement of the law in your country.

That caveat matters more than usual on this topic, because contract law, employment law and intellectual-property law all vary substantially between jurisdictions — and freelance work is very often cross-border. Two parties in different countries can each be perfectly reasonable and still hold incompatible assumptions about what happens by default. If the money, the confidential material or the intellectual property at stake is significant to you, have a qualified lawyer in your own jurisdiction review the agreement. For a $15 logo tweak, that is overkill; for a six-figure platform build, it is not optional.

Why a written agreement matters, even for small jobs

The practical case for writing things down has nothing to do with going to court, which almost nobody does over a freelance project because the cost of litigating exceeds the value of the work. It is about three much more ordinary benefits.

It surfaces disagreement early. The moment you write “three rounds of revisions”, you find out whether the freelancer thought it was unlimited. That conversation costs nothing on day zero and costs a great deal on day thirty.

It gives you something to point at. When a project drifts, the difference between an awkward conversation and a genuine dispute is usually whether there is an agreed reference point. “We said five pages” ends an argument; “I thought we said five pages” starts one.

It is the evidence if things do go wrong. Any resolution process — a platform’s, a mediator’s, a court’s — works from what can be shown. A written scope agreed before work started is the single most useful document you can produce.

None of that requires a formal deed. It requires a record that both parties saw and did not object to, in a place neither of you can quietly edit later.

What you may already have in writing

Before you draft anything, take stock of what already exists. When you buy through a marketplace, several documents are usually in place before you write a word.

• The listingA fixed-price service description states deliverables, inclusions and often revision counts. It is a written offer.
• The platform termsBoth parties have agreed a common rulebook covering conduct, payment, refunds and resolution.
• The order recordWhat was bought, for how much, and when — timestamped and not editable by either side.
• The requirements you submitYour written answers to the seller’s questions form part of the brief on the order.
• The message threadAnything agreed in platform messages is dated, attributable and visible to both parties.

For a great many jobs, that stack is genuinely sufficient. The gap it leaves is the project-specific detail: your particular deliverables, your deadline, and your position on ownership. Those are the things worth adding explicitly, and the fastest way to add them is a short message the freelancer confirms before starting — not a separate PDF that lives in an inbox.

The one thing that undoes all of it is moving the conversation off-platform. Once the record is scattered across personal email and chat apps, nothing is attributable and nothing is timestamped in a way either party can rely on. Keep the agreement where the order is.

The eight things a freelance agreement should cover

Whether it is a signed contract or a confirmed message, these are the points that actually get argued about later. If your agreement covers these eight, it is doing its job.

• Scope. What is being produced, in nouns and numbers. And, just as importantly, what is not.
• Deliverables and formats. The actual files you will receive, including source files if you need them.
• Revisions. How many rounds, what counts as a revision rather than a new request, and what happens beyond the limit.
• Timeline and dependencies. Dates, plus what the freelancer needs from you and by when. A deadline with no dependency list is a wish.
• Price and what triggers extra charges. The number, and the conditions under which it changes.
• Payment terms. When money moves and against what.
• Intellectual property. Who owns the finished work, and what each party may do with it afterwards.
• Confidentiality. What must not be shared, and for how long.

Two more are worth adding on anything substantial: a termination clause saying what happens if either party stops (who owns the partial work, what is payable), and a governing law line naming whose law applies and where any dispute would be heard.

Getting scope and revisions right

Scope is where most agreements are weakest, because it is the part that feels obvious when you write it and turns out not to be.

The test is whether a stranger could read your scope and tell you were finished. “A logo” fails that test. “One primary logo, one stacked variant, one monochrome variant, supplied as SVG, PNG and PDF, plus a one-page usage sheet” passes it. The second version takes ninety seconds longer to write and removes almost the entire category of end-of-project argument.

Revisions deserve the same treatment. Agree a number, and agree what a revision is. The distinction that matters is between refining the thing you asked for and asking for a different thing: changing the colour palette is a revision, deciding you now want a mascot instead of a wordmark is a new job. Say so up front and neither of you has to have that conversation awkwardly later.

It is also worth agreeing a review window — a period within which you will give consolidated feedback. Feedback that arrives in nine separate messages over three weeks is genuinely harder to work with than the same feedback in one message, and freelancers price for the difference whether or not it is discussed. Our guide on writing a project brief covers how to structure that up front.

Payment terms in plain words

Payment terms answer one question: what has to be true before money moves. The common structures are a single payment on completion, a single payment up front, or a split across stages for longer work. Each is normal in some markets and unusual in others.

What matters more than the structure is that the trigger is objective. “Payable on delivery of the final files” is objective. “Payable on satisfactory completion” is not, because “satisfactory” has no test attached, and both parties will define it in their own favour when it counts.

If you are buying through a marketplace, much of this is already handled by the platform’s own payment mechanism rather than by your agreement, and you should not duplicate it. What you still want in writing is the scope your payment covers, and what happens to the money if the work is not delivered — which on Zinn Hub is governed by our refund policy rather than by anything you draft.

One term to be wary of anywhere: an agreement that makes payment conditional on something entirely outside the freelancer’s control, such as the commercial performance of the finished work. That is a partnership dressed as a fee, and it usually ends badly for both sides.

Intellectual property: the clause people skip

This is the single most commonly omitted term, and the one most likely to matter years later — when you want to trademark a logo, sell the business, or reuse a design in a market nobody had thought about.

The short version is that in many jurisdictions the person who creates a work is its first owner, and paying for work does not by itself transfer ownership unless the agreement says so. Some jurisdictions have doctrines that change this for certain relationships, and the details differ significantly from country to country — which is exactly why it should be stated explicitly rather than assumed.

The practical distinction to understand is between an assignment, where ownership passes to you, and a licence, where the creator keeps ownership and grants you permission to use the work in defined ways. Both are legitimate. They are priced differently, and they lead to very different outcomes in five years’ time. We cover this in full in our guide on who owns the copyright when you hire a freelancer.

Whichever you agree, put three things in writing: what is being transferred or licensed, whether it is exclusive, and whether the freelancer may show the work in their portfolio. That last point is worth granting in most cases — portfolio rights matter enormously to freelancers and cost most buyers nothing — but if your project genuinely cannot be shown, say so before work starts rather than after it appears on someone’s profile.

What an NDA is — and what it is not

A non-disclosure agreement is a contract in which one or both parties promise not to disclose defined confidential information, for a defined period, and to use it only for a defined purpose. It is a confidentiality tool. That is all it is.

An NDA is frequently misunderstood as doing three things it does not do:

• It does not transfer IPConfidentiality and ownership are separate clauses. An NDA on its own leaves ownership exactly where it was.
• It does not protect an ideaIt restricts a specific person from disclosing what you told them. It gives you no rights against anyone who independently has the same idea.
• It does not enforce itselfEnforcement means proving a breach, proving loss and pursuing it across a border. That is expensive and slow.

Understanding that changes how you should use one. An NDA’s realistic value is mostly deterrent and definitional: it makes the confidentiality expectation explicit, which is a genuine benefit, and it signals seriousness. It is not a vault. The strongest protection for genuinely sensitive material is still not to send it — or to send a redacted version — until you have a working relationship.

Two terms you will meet alongside it: a mutual NDA binds both parties, which is normal and fair when the freelancer will also share methods or tooling; a one-way NDA binds only the recipient. Most freelance engagements suit a mutual one.

When an NDA is worth asking for

Asking for an NDA on a routine job is a common own goal. It adds friction, it can read as distrust, some freelancers will decline outright, and for a $20 task it protects nothing that matters. The right question is not “could this be confidential?” but “what specifically would harm me if it got out, and would this document meaningfully reduce that risk?”

Usually worth it: unreleased products or launch dates; commercially sensitive figures such as pricing models, margins or customer lists; personal data belonging to your own customers; source code or proprietary processes; anything under an existing confidentiality obligation you owe to a third party.

Usually not worth it: a logo, a landing page, a blog post, a routine edit, or an idea whose value lies entirely in execution. If a competitor learning what you are doing would not change anything, the NDA is administration rather than protection.

If you do need one, raise it before you send the brief, not after — and be realistic about scale. A short, clear, mutual NDA that a freelancer will actually sign beats a twelve-page instrument that stalls the project for a fortnight. It is also worth checking that its restrictions are proportionate: courts in many jurisdictions look unfavourably on confidentiality obligations that are unlimited in time and scope, so a perpetual, universal clause can be weaker in practice than a narrow, well-defined one.

The terms inside an NDA

Whatever template you use, read these five clauses properly, because they are what determine whether the document does anything.

• The definition of confidential information. Too narrow and it misses the thing you cared about; too broad (“all information howsoever disclosed”) and it becomes hard to enforce. Marking material as confidential when you send it is a simple, effective habit.
• The permitted purpose. The recipient may use the information only to perform the work. Without this, you have restricted disclosure but not use.
• The exclusions. Standard and reasonable: information already public, already known to the recipient, independently developed, or required to be disclosed by law. An NDA with no exclusions is a warning sign about whoever drafted it.
• The duration. A defined term — commonly a small number of years after the engagement ends — is more enforceable in many jurisdictions than “forever”, with the usual exception of genuine trade secrets.
• Governing law and jurisdiction. Which country’s law applies and where a dispute would be heard. In a cross-border engagement this is the clause that decides whether enforcement is realistic at all.

Watch for a clause that quietly does something other than confidentiality — an IP assignment, a non-compete, or a broad non-solicitation buried in an NDA. Those are substantive commitments and belong in a document you have read as such, whichever side is proposing them.

How this works on Zinn Hub

Zinn Hub does not draft, host or witness contracts between buyers and Zinners, and it does not provide NDA templates. What it does provide is a framework the agreement sits inside, and it is worth knowing which parts you do not need to write yourself.

The platform terms already bind both sides. Our terms and conditions set out a shared rulebook covering conduct, payment, refunds and resolution, and both parties accept them before transacting.

Ownership of deliverables has a stated default. The terms provide that intellectual property rights in service deliverables are determined by the agreement between the Zinner and the Zinnector, and that unless otherwise specified the Zinnector receives rights to use the deliverables for their intended purpose, the Zinner may retain portfolio rights unless explicitly waived, and specific IP terms should be clarified in the service description, proposal or direct communication. In other words: the terms tell you to agree it, and give you a fallback if you do not.

Data handling obligations already apply. Where a Zinner receives personal data, files or credentials from a buyer while delivering an order, the terms require them to handle it in line with applicable data protection law, maintain confidentiality as specified in their store policies, use it only for that order, securely delete it within 30 days of order completion unless a longer period is agreed, and notify you and Zinn Hub of any breach. That is a meaningful baseline before any separate NDA.

You can keep a brief private. When you post a project, you can set its visibility to Invite Only. The project is then hidden from the public Projects hub and only freelancers you personally invite from the freelancer directory can view it or propose. That is often the more useful control for a sensitive brief than an NDA is, because it limits who ever sees the material.

Keep the record on the platform. Scope agreed in platform messages is dated and visible to both parties, and it is what a resolution process works from if a job goes wrong. Our guide on handling a dispute with a freelancer explains what that process looks like in practice.