How to record your background IP before a client contract

Flat illustration of a monitor with source code, a locked server and a calendar with the release date, with a timestamp badge

Background IP is the material you owned before a project started, such as code libraries, templates, design systems, photos or methods. A client contract may treat it differently from the work you create for that client, so read your own contract. The best time to record it is before you sign. List the files and folders you plan to reuse, then timestamp them. TimeBinder® records each file’s fingerprint on the Bitcoin blockchain without uploading the file. Later, you can check that the file existed no later than the recorded time and still matches its fingerprint. A TimeBind doesn’t show who created the material or decide who owns it. Your contract and the law decide that, so ask a lawyer about the wording.

Table of Contents

What background IP is, and why a dated record helps

Contracts use different names for it: background IP, pre-existing materials, or prior work. The idea is the same. It is what you bring to the project, as opposed to what you make for the client during it. Your own contract sets the definitions, so read it closely and ask a lawyer if anything is unclear.

The trouble usually starts later. A client sees your starter template in their finished site and assumes they paid for it. A new project manager asks why the same component library turns up in another client’s product. Or someone doubts that you built a tool before the engagement began.

At that point, saying “I’ve had this for years” is not much help. A dated record of the exact files you had before signing gives everyone something to check. It doesn’t settle who owns what. It does show that those files existed no later than a set time, before the project started.

Step 1: list it

Write a plain list of what you’ll reuse. For each item, note:

  • a short name and description, such as “starter theme v3” or “invoice PDF generator”
  • where it lives: a folder, a repository or an asset library
  • the version or release you’ll bring to the project
  • roughly when you first made it, if you know

Be specific. “My code” is hard to match to anything later. “auth-module, release 2.4, in the archive auth-module-2.4.zip” is easy to match.

Keep the list itself as a file, such as a PDF. You’ll timestamp it in the next step.

Step 2: timestamp the files before signing

Gather the exact files your list points to. For folders or code, make an archive (a zip) of each version, so one file stands for the whole folder at that moment.

Then TimeBind them. Each file is fingerprinted on your own device, and only the fingerprint is recorded on the Bitcoin blockchain. You can add up to 10 files to one TimeBind, such as your list plus the archives it names. You get a Proof of Time Certificate.

Store the exact files and the certificate together, with backups. If you re-zip a folder later, the new archive is a different file with a different fingerprint, so keep the original archive.

For code, timestamping source code covers release archives and commit lists. That page also notes that Git dates come from the committer’s machine and history can be rewritten.

Step 3: refer to the list in the contract

You may want to attach or refer to your list of pre-existing materials in the contract or statement of work. Whether to do that, and how to word it, is a question for your lawyer. This page doesn’t suggest clause wording.

What you can do on your own is keep the list, the archives and the certificate in one place with your signed contract. If a question comes up, you can then point to the exact files and the time they were recorded.

Code, templates, design systems and photo libraries

  • Code. Archive each library or module at the version you’ll reuse. Include a commit list if you have one.
  • Templates and themes. Timestamp the master template files, not a client’s customised copy.
  • Design systems. Export the component library or source file as it stands before the project. See how to protect your design before sending it to a client.
  • Photo and asset libraries. Archive the folders you’ll license into the project, at full resolution.

If you work through an agency, or run one, see timestamping for agencies. For solo work, see timestamping for freelancers.

Timing matters in ownership disputes. For an example of how sketches and timing were argued over in court, read about the Bratz sketches case. If a client has already used your work without paying, see what to gather when a client used your design without paying.

What a TimeBind does not show

  • It doesn’t show who created the material, that it’s original, or whether AI was used.
  • It doesn’t decide who owns it. Your contract and the law do.
  • It doesn’t show how a client, court or other party will treat it.
  • It records the time you made the TimeBind, not the day you first wrote the code or drew the template.

This is general information, not legal advice.

When TimeBinder isn’t the right tool

  • You need contract wording. Ask a lawyer. A timestamp can’t draft or interpret a clause.
  • The files no longer exist in their earlier form. A TimeBind can only record the files you have now.
  • You need someone to say who owns the work. That’s a legal question, not a timestamp.

Frequently Asked Questions

  1. What counts as background IP?

    It is usually material you owned before the project started, such as code, templates, design systems, photos or methods. Your contract sets the exact definition, so read it and ask a lawyer if it’s unclear.

  2. Should I list background IP in the contract?

    Whether and how to list it is a question for your lawyer. Keeping your own dated list of the files you’ll reuse helps either way, because it points to exact files.

  3. Can I timestamp a whole code repository?

    Yes, as an archive. Zip the repository at the version you’ll reuse and timestamp the zip, along with a commit list if you have one. Keep that exact archive, because re-zipping makes a new file with a different fingerprint.

  4. Does a timestamp show I own my templates?

    No. It shows that the exact template files existed no later than the recorded time and still match their fingerprints. Who owns them depends on your contract and the law.

  5. What if the client says I built it during the project?

    If you timestamped the files before signing, you can show they existed no later than that earlier time. That helps your timeline, but it doesn’t settle ownership. Get legal advice for the dispute itself.

Record your background IP before you sign

Start by timestamping your list and the files you’ll reuse on your next project. See plans and pricing

Recent Posts