Skip to content

Legal

IP & Code Ownership Position

Last updated October 22, 2026

Future Built Digital believes ownership should be explicit before work starts.

This page describes our default commercial position. It is not a substitute for the intellectual-property terms in a signed proposal, statement of work, master services agreement, license, or other project agreement.

1. Client-provided materials remain the client's

The client retains ownership of materials it provides to Future Built, including, as applicable:

  • brand assets;
  • copy;
  • data;
  • documents;
  • internal business information;
  • product materials;
  • existing software and code;
  • client-owned configurations;
  • proprietary processes.

The client is responsible for having the rights needed to provide those materials for the project.

2. Bespoke deliverables are intended to be usable by the client

Our default objective is not to trap a client behind agency-controlled code.

For fully paid work, the applicable project agreement should define the client's rights to bespoke deliverables created specifically for the engagement.

Depending on the project, those deliverables may include:

  • application/source code;
  • custom UI and design work;
  • project-specific schemas and workflows;
  • integration code;
  • project-specific documentation;
  • content or configuration created for the client.

Where the business expects to operate the system independently, the project should also define an appropriate handoff path.

3. Future Built retains background IP and reusable building blocks

Future Built retains ownership of intellectual property that existed before the project or is developed as a reusable/general-purpose asset rather than uniquely for one client.

Examples may include:

  • internal frameworks;
  • libraries;
  • templates;
  • reference architectures;
  • generic components;
  • design-system primitives;
  • reusable automation patterns;
  • development utilities;
  • scripts and tooling;
  • internal prompts and workflow scaffolding;
  • generalized methods, know-how, and implementation patterns.

This is what allows Future Built to compound delivery knowledge rather than rebuild commodity foundations from zero.

A client project should not lose the ability to operate merely because a reusable component is present. Where retained Future Built IP is embedded in a deliverable, the project agreement should provide the client the license needed to use the delivered system as intended.

4. Third-party and open-source software

Third-party software remains subject to its own license and terms.

This includes:

  • open-source dependencies;
  • commercial libraries;
  • SaaS platforms;
  • APIs;
  • cloud services;
  • fonts and media;
  • model providers;
  • client-selected vendor systems.

Future Built cannot transfer ownership of third-party technology we do not own.

We prefer mature commodity infrastructure where it reduces unnecessary custom code, but we should make material dependencies visible.

5. Client accounts and infrastructure

Where practical, production services that materially belong to the client's ongoing operation should use:

  • client-owned accounts;
  • client-controlled billing;
  • documented access;
  • explicit roles/permissions.

In some projects Future Built may temporarily host or administer infrastructure. Ownership, billing, transfer, and ongoing access should be defined before handoff.

6. Credentials and access

Credentials are not intellectual property.

At project completion or termination, access should be reviewed and, where appropriate:

  • transferred;
  • revoked;
  • rotated;
  • documented.

Future Built should not retain production access indefinitely merely because we originally built the system.

7. Data ownership

Client business data remains the client's data unless a written agreement expressly states otherwise.

Future Built may create:

  • normalized representations;
  • logs;
  • derived technical metadata;
  • backups;
  • temporary copies;

as reasonably necessary to deliver or support the system.

The project agreement should define unusual retention, residency, export, deletion, or regulated-data requirements.

8. AI-assisted work

Future Built may use AI-assisted engineering and content tools.

AI assistance does not by itself change the project's agreed ownership allocation.

However, because laws and provider terms around machine-generated material continue to evolve, we do not promise that every isolated AI-generated fragment is independently copyrightable or exclusive.

Future Built remains responsible for assembling and delivering the project work described in the agreement.

9. Portfolio use

Future Built may request the right to reference completed work in our portfolio, subject to:

  • client confidentiality;
  • contractual restrictions;
  • security considerations;
  • approval requirements;
  • redaction where appropriate.

For confidential or private work, the project agreement controls whether any public reference is allowed.

Future Built will not turn constructed work into an implied historical client engagement.

10. Project agreement controls

If a project requires:

  • complete assignment of all custom code;
  • work-made-for-hire treatment;
  • exclusive licensing;
  • restrictions on reusable components;
  • open-source disclosure requirements;
  • source-available escrow;
  • special confidentiality;
  • regulated data terms;

those requirements should be negotiated explicitly.

Questions may be sent to:

Future Built Digital
Email: dakota@futurebuiltdigital.com