Selling design files and product history for AI training: Figma and beyond

Yes: a company can license its own design files to AI buyers, and the most valuable version is not a folder of mockups but the design with its history and the code that shipped from it, because together they teach a model to go from intent to interface. Buyers name the tool: Handshake AI lists Figma among the sources it buys, and a closed startup's workspace data in Google, Notion, Figma and Slack was being sold beside its code base this month. Figma's terms say that "As between Customer and Figma, Customer retains all right, title, and interest in Customer Content", and editors can save files locally as .fig and export assets as PNG, SVG and PDF; our records do not confirm a bulk export of a whole organisation. What usually is not yours to license sits inside the files: work you made for clients, and licensed assets such as fonts, icon sets, UI kits and stock images, whose licences usually forbid resale or sublicensing. So the steps are: count what you hold, export it yourself while the subscription is live, take out client work and third-party assets, remove the personal data in designs and user research, and put the description of the whole record before every buyer that fits at once.

This guide is for a founder, head of design, officer or trustee of a company, operating or closed, whose product thinking lives in design files: Figma first, and the specifications, tickets, prototypes and code around them. It covers what buyers value in design work, what Figma lets you export, client work and third-party assets, who owns designs made by employees and contractors, personal data in designs and user research, what design files fetch, preparing and delivering them, the case of a closed company, and how a sale through AIData.Broker works. Every quote comes from the page it names, read on the day shown in its record. Where no record covers a point, the guide says so rather than guessing.

This guide is research from public sources, not legal advice.

Contents

1. What design files hold, and what buyers value in them
2. Design with its code: the pairing buyers look for
3. What buyers leave out
4. Getting design files out of Figma
5. Figma's own AI training, and why it matters to an exclusive licence
6. Client work, fonts, icons, stock images and UI kits
7. Who owns the designs: employees, contractors and agencies
8. Personal data in designs and user research
9. What design files fetch
10. Preparing and delivering design files
11. A closed company's design files
12. How a sale through AIData.Broker works
13. Questions people ask
14. What this means for you

1. What design files hold, and what buyers value in them

A company's design files are the record of how it decided what its product would look like and how it would behave. A Figma file for a feature usually holds more than the final screen. It holds the early explorations that were discarded, the flows that connect one screen to the next, the components that make up the design system, the comments in which a product manager asked why a button moved and a designer answered, the prototype links that were shown to users, and the handoff notes an engineer read before building it. Across a few years, a product team's files show a product taking shape: what it looked like at launch, what changed after each round of research, which patterns became standard and which were dropped.

Very little of this is public. The web is full of finished interfaces, because every shipped product is visible to anyone who opens it, and full of polished portfolio shots. It holds almost none of the work in between: the brief, the rejected options, the reasoning, the component library as a working system, and the link from a design to the code that implemented it. That in-between material is what a model needs if it is to help with design work rather than imitate the look of finished screens.

Buyers say so in the way they describe what they take. Handshake AI's data partnership page lists, among "Examples of sources we buy", Figma beside AutoCAD, Google Drive, Notion and Slack. Scale's data partnership page asks for project records "carried over with their complete history and metadata", and for files "File contents plus their metadata, authorship, timestamps, and access permissions". Turing, which buys whole company records, says that "Communications, tickets, wikis, and databases stand on their own and are often the most valuable part." And Troveo, a buyer, tells holders to export "design docs and ticket archives, before any subscription lapses" beside the repository.

The closest public sale to a design team's record is a small one. MIT Technology Review reported in October 2026 that the founder of a closed crypto startup had netted roughly $25,000 for his code base through SimpleClosure's asset marketplace, with a still-pending amount, likely around $15,000, for the workspace data in Google, Notion, Figma, and Slack. The Figma files were part of a workspace, sold beside the code and the chat, not on their own. That is the pattern this guide returns to.

Five kinds of design material carry most of the value.

Flows with their reasoning. A file that moves from a brief through explorations to a chosen design, with comments that record why, is a complete example of product judgment. A page of final screens with nothing behind it is worth much less, because a model can already see finished interfaces anywhere.

Design systems. A component library with its variants, tokens, usage notes and the history of how it changed is a structured description of how a product is built. It maps closely onto code, because the components in the design file usually have counterparts in the front-end code.

Handoff and specification. Annotations, redlines, interaction notes and the written specifications that accompany a design connect it to the build. These are the documents DataVendor, a buyer of codebases, asks to come with code: "architecture or product notes" and "any docs that explain what the code does".

History. Versions, branches and comments show a design changing over time and the people who changed it. Scale's words, "complete history and metadata" and "authorship, timestamps, and access permissions", are a buyer telling you that a file reduced to its final frame is a smaller asset. Section 4 covers what an export keeps.

Links to tickets and code. A design that links its ticket, a ticket that links the pull request, a pull request that links the design: each ties the file to the work around it. Sunset, a wind-down firm that buys closing companies' records, told Forbes it prices on how well records connect across systems, and that a ticket tied to a specific code commit is worth more than a standalone document. SimpleClosure makes the same point about code: less common languages "can fetch top dollar", and "Even better if you've got context from Jira, Linear or Figma".

That last point is the one to hold on to. In the public records, design files are bought as part of a company's record, where they explain what the tickets and the code were for. Collinear, a buyer, lists among what it does not need "Loose documents with no company around them", and a folder of exported screens with no product around it is close to that.

2. Design with its code: the pairing buyers look for

The reason design files matter to AI buyers in 2026 is the work models are now asked to do. Coding models are asked to build interfaces from a description or a mockup, and agents are asked to work inside design tools themselves. A model that is to turn a design into working code learns from examples where both exist and are linked: this frame became this component, this flow became these routes, this change to the design became this pull request.

The public records show buyers assembling that link from several directions.

From the code side. Turing's process page for codebases asks for "Screenshot of the running application" beside its other requirements, so the buyer sees the interface the code produces. Troveo asks for "design docs and ticket archives" with the repository. Turing also pays a stated rate for what it calls org artifacts, "tickets, specs, docs, support threads", at $50 per artifact when bundled with a codebase. Our records do not show a Figma file named as one of those artifacts, and no record covers whether a design file counts as one, so treat that rate as a reference for specification documents, not a price for designs.

From the tool side. Prime Intellect's environments program, which pays developers to build training environments for AI agents, lists a bounty for an MCP backend simulator and agent environment for Figma at $2,000 per environment. That is a payment for building a simulated tool, not for a company's files, but it shows that agents working in design tools are being trained, and that they need examples of real design work to practise on.

From the people side. AI companies also pay designers to produce design judgments to order. xAI has advertised an AI Tutor, Design role at $35/hour to $75/hour. That is a wage, not a licence price, but it shows a buyer paying for exactly the reasoning that a company's design history already holds.

What none of our records shows is a buyer that publishes a price for a design-to-code pair as such: a linked set of design files and the code that implements them, priced per pair, per screen or per file. The guide does not invent one. What the records do support is the direction: a design team's files are worth most where they arrive with the code, the tickets and the documents that connect them, which is why section 9 prices them as part of a company's record and as part of a codebase.

For a holder, the practical meaning is simple. If you sell your code, sell the designs with it, linked. If you sell your workspace, keep the Figma files in it, with the links between designs, tickets and pull requests intact. The codebase guide and the Jira and issue history guide cover the systems your designs link to.

3. What buyers leave out

A design workspace collects far more than the company's own work. Over the years it fills with client projects, downloaded UI kits, community files duplicated from other designers, icon sets, stock photographs pasted into mockups, licensed fonts, screenshots of competitors' products, and user research full of real people. A buyer's counsel works through the same list of questions for every records sale, and several of them are about exactly this material. Our rights reference holds the full list; these are the ones that decide what leaves a design workspace.

Figma's own record in our rights reference says the same in one line: design files are usually the company's own work product and low personal-data risk, but they often embed client brand assets, licensed fonts, stock imagery, and third-party UI kits whose licences forbid redistribution.

Two kinds of exclusion follow, and they are done differently. The first is by place: a team, a project or a file that is out of scope as a whole (every client project, the research repository, a customer's white-label space). In a design workspace most excluded material sits in a few such places, because agencies and product teams usually organise files by client or by product, and excluding those places is cheap and auditable. The second is by layer: a licensed font used in an otherwise clean file, a stock photograph dropped into a hero section, an icon set imported as a library, a real customer's name in a table mockup. Those need a pass through the files themselves. Do the first before the second; it shrinks what has to be read.

What remains after both is the company's own design work on its own product: its flows, its design system, its explorations, its comments and its handoff notes.

4. Getting design files out of Figma

The export is the first practical question, and the answer from our records is partial.

What Figma's terms say. Figma's Terms of Service, effective 11 March 2026, state in section 2.8 that "As between Customer and Figma, Customer retains all right, title, and interest in Customer Content, and Figma owns all right, title, and interest in the Services." Our record marks the export as allowed. There is one exception in the terms, which our record also notes: on termination for breach of the export-control clause, the customer loses all right, title, and interest to Customer Content. For an ordinary company that has not breached export controls, the files are the company's as between it and Figma.

What an editor can export. Our record says that files can be saved locally as .fig and assets exported (PNG, SVG, PDF) by editors. A .fig file is Figma's own format, which keeps the file's structure (pages, frames, layers, components) so that it can be opened in Figma again. PNG, SVG and PDF exports are flat outputs: pictures of frames, vector drawings of assets, or documents for review. They lose most of what makes a design file valuable to a buyer: the components and their variants, the auto-layout rules, the prototype connections, the comments and the history.

What our records do not confirm. Our record says plainly that bulk organisation export not verified. No record we hold confirms whether a whole organisation's files, with their version history and comments, can be exported in one step, or whether version history and comments survive a .fig download. Before you describe your design files to a buyer, test it yourself: take one file with a long history and many comments, save it as .fig, open the copy in a fresh account, and see what came with it. Then agree in the licence exactly what is delivered.

What a holder can do in practice. Because no bulk export is confirmed, plan for a file-by-file export run by someone in your own team with edit access to every file, or by Figma's admin tools if your plan offers them. Keep a manifest as you go: every file's name, team, project, created and last-modified dates, number of pages and frames, and whether it was exported as .fig, as flat images or both. That manifest is also the inventory buyers ask for. Troveo's licensing guide asks for "A list of the systems you run and the years each one covers, your customer contracts and employee agreements, and a first view of what you'd keep out."

The API route. Figma also offers a developer API and a design-to-code server for AI tools. Our record of Figma's Developer Terms, effective 5 May 2026, found no clause on using API or MCP data to train AI, and notes that section 8(a) says Figma owns the developer resources, the services "and any data derived from either". That clause concerns data derived from Figma's services, and no record we hold settles how it applies to a customer's own files pulled through the API for a licence. For a holder the safe route is the one the other vendors' terms point to in our sister guides: your own team's export of your own files, not a buyer's connector reading your workspace. The documents and shared drives guide explains why the route matters for Google Workspace and Microsoft 365.

Beyond Figma. Many teams hold design work in other places too: older files in Sketch or Adobe XD, prototypes in other tools, brand assets in shared drives, design specifications in Confluence or Notion, and design tickets in Jira or Linear. Our rights reference holds no record for Sketch, Adobe XD or other design tools, so this guide makes no claim about their terms or exports. For the documents and tickets around your designs, the documents guide covers Google Drive, SharePoint, Confluence and Notion, and the Jira guide covers issue trackers.

5. Figma's own AI training, and why it matters to an exclusive licence

Figma trains AI on customer content in some cases, and that matters to a buyer that wants exclusivity.

Our record of Figma's terms notes that content training is an admin setting: per Figma's help pages, Starter and Professional teams default to content training on, Organization and Enterprise teams default to off, and training began 15 August 2024. Our record took that from a search excerpt of Figma's help page, so check your own admin settings rather than relying on the default.

The consequence for a sale is in our record's note: "If the team was on Starter or Professional with content training on, Figma may already have trained on the files: disclose to a buyer seeking exclusivity." The rights question that covers this, whether a software vendor has already used the content to train its own AI, names Figma among its examples. It does not stop a sale, but a buyer paying for exclusivity will want to know. The good answer is that you list each vendor's AI-training setting and when it was switched off, and the licence states exclusivity only against third parties you control. The red flag is promising that the material was never seen by any AI when the workspace sat on a plan where vendor training defaulted on.

So before any buyer conversation, write down three things for each Figma team: the plan it was on and when, the content training setting, and the date it was switched off if it was. Do the same for any other tool the designs lived in. A non-exclusive licence is not affected by this; an exclusive one is priced on it.

6. Client work, fonts, icons, stock images and UI kits

This is the section that decides most design sales, because design files are unusually full of material that is not the company's to license.

Client work. Agencies, studios and freelancers design for clients. A services agreement usually assigns the deliverables to the client, licenses them to the client, or at least makes the work confidential. The confidentiality question in our rights reference says NDAs and partner contracts usually limit use to a stated purpose and survive termination. A client project in your workspace is, in almost every case, out of scope unless the client agrees in writing. That includes the explorations the client never saw, because they were made under the same agreement. An agency that wants to license its design history usually licenses its own internal work (its brand, its tools, its own products) and leaves client projects out, unless it obtains each client's written consent.

Customer designs inside a product. A product company may hold designs it made for its own customers: custom themes, white-label versions, customer logos in onboarding flows. Where you hold material for a customer, the question on customer contracts says you may use them only on their instructions. Treat these like client work.

Fonts. Commercial fonts are licensed, and the licence governs how the font files and the rendered type may be used. Our records hold no reading of any particular font licence, so this guide makes no claim about what a given foundry allows. What our records do say is general: licences for bought material "usually forbid resale or sublicensing, so it usually cannot be passed on to a lab without the licensor's consent". In practice, a design file references a font by name and the font files themselves live on the designer's machine or in Figma's font service, so a .fig export does not usually carry the font files. Check your exports, leave out any font files, and list the fonts the files use so a buyer's counsel can see what is referenced.

Icons, illustrations and stock images. Icon sets, illustration packs and stock photographs pasted into mockups are third-party material under their own licences. The same question applies: Licensed third-party data. The good answer is that "Bought and licensed material is identified and removed before packaging, and the provenance file shows what remains is the company's own." For design files that means replacing licensed images with placeholders, or removing the frames that hold them, and keeping a list of what was removed.

UI kits and community files. Teams often start from a bought or downloaded UI kit, or duplicate a community file. A design system built on a third-party kit carries the kit's licence into every component made from it. The copyright question covers text, images, video or files created by others that you do not own. A design system the team built from scratch is the company's; a kit it bought or copied is not, and a system that is a lightly edited copy of one sits in between. List the origin of every library your files use.

Screenshots of other products. Moodboards and competitive reviews are full of screenshots of other companies' interfaces. Those are other people's copyright material. They are easy to find (they usually sit in pages or files named for research, inspiration or competitors) and easy to exclude by place.

Why buyers' counsel care so much is set out in our fair use guide: in September 2026 the Third Circuit held in Thomson Reuters v. ROSS Intelligence "that Thomson Reuters's materials are copyrightable and that ROSS's use was not fair". For a holder, the lesson is not about fair use at all: you cannot license what you do not own, and a buyer will ask you to warrant that what you deliver does not infringe. The source counsel cite for that warranty says buyers want a promise "That the use of the data for training as specified in the agreement does not infringe a third party's copyright".

7. Who owns the designs: employees, contractors and agencies

Figma's terms settle ownership between you and Figma. They do not settle it between you and the people who made the designs. The IP assignment question says why: "SaaS terms say the customer owns its content only as between it and the vendor, not against its own contractors." The words "as between Customer and Figma" in Figma's terms mean exactly that. Three groups of designers are in a typical workspace.

Employees. Under US copyright law, a work "prepared by an employee within the scope of his or her employment" is a work made for hire, and for a work made for hire "the employer or other person for whom the work was prepared is considered the author", unless the parties have expressly agreed otherwise in a signed written instrument. A flow a product designer drew as part of the job, a component library the design team maintained, a prototype made for a research round: these belong to the company. The limit is in the words "within the scope of employment". A designer's personal portfolio pieces kept in a company team, side projects, or files made before the person joined are not covered by the definition and belong in the exclusion pass.

Contractors, freelancers and agencies. A contractor is not an employee, and the second branch of the same definition covers only works "specially ordered or commissioned" for a narrow list of uses. Design work commissioned from a freelancer or a studio (a brand identity, a website design, a product redesign, an illustration set) belongs to the company only if the designer signed an assignment. This is common in design: many companies' brand and first product designs were made by an outside studio. The good answer to the IP assignment question is "Signed invention and IP assignment agreements for all contributors, including contractors and agencies; gaps listed and excluded." The red flags are "Freelancers or agencies without written assignment" and "founders who never assigned pre-incorporation work". The last one matters for design too: a founder who sketched the first version of the product before the company existed may still own those files personally.

In a Figma workspace, contractors' work is usually easy to find: outside collaborators appear as guests, and their files sit in projects named for the studio or the engagement. List them, check the agreements, and exclude what has no assignment.

The authority to sell. The licensor must be the company, not a founder or a designer personally. Buyers ask that "The legal entity that collected the data is the licensor; the board has approved the licence in writing", and the red flag is "A founder selling personally after a shutdown, a former employee holding an export, or no board resolution." A designer who kept copies of the company's files after leaving cannot license them; neither can a founder acting in a personal capacity.

8. Personal data in designs and user research

Our rights record calls design files low personal-data risk, and for the design work itself that is fair: a component library or a flow diagram rarely names a real person. Three places in a design workspace are different.

Real data in mockups. Designers often fill mockups with realistic content, and sometimes with real content: a screenshot of the production admin panel with customers' names and emails, a pasted export of real orders to test a table layout, real support messages in a design for the help centre. Each is personal data, and some of it may be your customers' data that you hold for them, which brings back the customer contracts question: you may use it only on their instructions. Search the files for text that looks like names, email addresses, phone numbers and account numbers, and replace it with invented content.

Faces and people in images. Team photos, avatars of real users, photographs from events and stock images of people appear throughout design files. The photo guide covers images of people in detail; for design files, the simplest course is to replace real avatars and photographs with placeholders, since the design value lies in the layout, not the face.

User research. Research repositories hold interview recordings, transcripts, notes on named participants, survey responses and usability test videos. This is the densest personal material a design team keeps, often of members of the public, collected under a consent form for the purpose of improving the product. No record we hold covers what research consent forms typically allow, or whether research participants' data can be licensed for AI training under them, so this guide makes no claim on that. The counsel the sister guides cite advise excluding high-risk material entirely: "Exclude high-risk data entirely rather than relying on de-identification." For most design teams, the research repository is a place to exclude as a whole. Research findings written up in the team's own words, with participants removed, are a different matter and can stay with the design documents.

Names in comments and history. The comments, version history and authorship that make a design file valuable also name the people who made it. Replace names with stable pseudonyms, so that a buyer still sees that the same designer made the explorations and answered the comments, without seeing who it was.

Every buyer that takes company records expects personal data to be removed before or as part of delivery, and who does it differs. Scale says it "anonymizes everything inside your environment, before any data is extracted". Turing says "Personal data and secrets are removed before anything reaches a model" and that "you approve scope before we begin". In most of these models someone other than you reads your raw files first, so decide which you accept before you choose a buyer.

Our de-identification standard sets out the method we advise: removal before anything leaves you, by you or an independent provider you choose, with a group-size floor of 11 for any delivery and 300 random records read by a person before it goes. Our free de-identification tool runs in your own browser and reads office files and PDFs, so exported specifications and research write-ups can be checked on your own computer. On company Slack, email and documents it measured an F1 of 86.8%, finding 95.8% of people's identifiers. It reads text, not the pictures inside a design file, so real names in mockups need the search described above, and no tool is perfect, which is why the standard pairs it with a person's review before transfer. California's law also attaches commitments to deidentified information: the business must "Publicly commit to maintain and use the information in deidentified form and not to attempt to reidentify the information".

9. What design files fetch

No record we hold gives a public price for design files on their own: no buyer publishes a rate per Figma file, per screen or per design-to-code pair. What the records do give is three reference points, and a holder should read design files against all three.

As part of a company's record. This is how the one public sale that names Figma priced it. The closed crypto startup's workspace data in Google, Notion, Figma, and Slack was expected to bring likely around $15,000, beside roughly $25,000 for the code base; the transaction is in our records as one log entry. Across every public offer for one company's records, the middle half sits at $174K to $693K per company, and the median of the sales that actually happened is $28.3K per company. Design files raise a company record's value where they connect to its tickets and code; they do not carry a separate line in any record we hold.

As part of a codebase. Where designs travel with the code that implements them, the code price is the anchor. Public prices for source code put the middle range at $934 to $24.2K per repository per repository, and the median of sales that happened is $1,579 per repository per repository. Turing's stated rate for specs and docs bundled with a codebase, $50 per artifact, is the nearest published price for the documents around code. SimpleClosure's remark that code is worth more with context from Jira, Linear or Figma is the clearest public statement that designs lift a codebase's price, though it puts no number on the lift.

As images. Exported screens are pictures, and the image market prices pictures. Across public prices for images, the middle range is $0.27 to $5.27 per image per image, and the median of sales and payouts that happened is $0.029 per image per image. Curated images with metadata sell for up to 100x the lowest bulk rate, and the valuation prices professional image libraries with metadata at $0.25 to $2 an image. This is the floor, not the target: flat exports throw away the structure, history and links that buyers of company records ask for, and price the work as pictures. The photo guide explains how image libraries are priced.

The rates page computes these figures from every public price at once, and they move as records are added. For your own files, the valuation returns a range from your answers about your systems, with no upload.

10. Preparing and delivering design files

The preparation is the same work in the same order as for any company record, with a few steps specific to design.

1. Keep the subscription paid. Figma files live in Figma. Our records hold no reading of how long Figma keeps a cancelled team's files, so do not cancel before the export is done and checked.
2. Count what you hold. Teams, projects, files, pages and frames; the years they cover; how many designers worked in them; how many files have prototypes, comments and long version histories; and which files link to tickets and pull requests. Buyers price on these counts, and the valuation asks for them.
3. Write down the training settings. For each Figma team, the plan, the content training setting and the date it changed (section 5).
4. Map and exclude by place. Mark every client project, customer space, research repository, moodboard and competitor review as out of scope (sections 3 and 6).
5. List the libraries and assets. For every file in scope, the fonts it uses, the component libraries it imports and where each came from, and any stock images, icons or illustrations in it. Remove or replace what is licensed.
6. Check the assignments. List outside contributors and match each to a signed assignment; exclude what has none (section 7).
7. Export it yourself. Save files in scope as .fig, and export flat images of key frames as well if the buyer wants them. Test that history and comments come with a .fig before relying on it (section 4). Keep the manifest.
8. Keep the links. Export the tickets and the code the designs link to at the same time, so the links still resolve to something in the delivery. The Jira guide and the codebase guide cover those exports.
9. De-identify. Replace real data in mockups, real faces and avatars, and names in comments and history (section 8).
10. Write the note. Troveo asks holders to "package the exports with a short note on what each system was used for and over what dates". For design files, say which product each team covered, which years, which design system version, and how designs link to tickets and code.

Delivery runs from you, or a de-identification provider you choose, to the buyer, under the licence you signed. Agree in the licence what is delivered (.fig files, flat exports or both; with or without history and comments), what was excluded and why, and what the buyer may do with it. Do not share samples before the rights review: the question on samples warns that a sample is itself a disclosure, so any sample should come from the reviewed, de-identified set under an NDA.

11. A closed company's design files

A closed company's design files can often still be licensed, if they still exist and the right person signs.

Who signs. In Delaware, a dissolved corporation continues for three years to wind up its affairs, and in a bankruptcy the trustee acts for the estate. The licensor is the company acting through whoever has authority in the wind-down, not a former founder or designer personally ( authority to sell).

Whether the files exist. This is the practical question. Design files live in a paid cloud tool, and a closed company often stops paying its subscriptions first. No record we hold says how long Figma keeps a cancelled team's files, so treat every day after cancellation as a risk. If the team is still active, export now (section 10). If it has been cancelled, contact Figma's support as the company and ask what can be recovered; the records give no basis for expecting either outcome. Former designers' local copies are not a substitute: a copy held by a former employee is the red flag in the authority question, not a route to a sale.

What sells. The one public sale that names Figma is a closed company's: the crypto startup whose founder sold its code base and whose workspace data in Google, Notion, Figma, and Slack was pending sale through SimpleClosure. Wind-down buyers take the whole record, and the design files add value where they connect to the code and tickets.

The estates page covers the closed-company path in full, including who can sign in each situation.

12. How a sale through AIData.Broker works

AIData.Broker represents companies selling their data to AI buyers. We act for the holder, as its agent in the sale, for holders based in the United States, the United Kingdom and Canada. For a holder of design files and product history, a sale through us runs like this.

The valuation comes first, with no upload. The valuation asks about your systems (which design and product tools, how many years, how many people, what else the company ran) and returns a range from the public records in section 9. If you add files, they are measured on your own computer. The valuation binds no one.

You deliver the files yourself. You, or a de-identification provider you choose, deliver to the buyer, and the buyer pays you. That keeps your design files on the route Figma's terms describe: your own team's export of your own content.

Every buyer that fits sees it at once. Every buyer whose published requirements fit your records receives a description that does not identify you; each that gives its confidentiality undertaking receives the same datasheet, with one deadline for offers. Offers come back on the same terms, so you can compare price, de-identification model, payment timing and exclusivity side by side. Our free offer check reads any offer you already have against the published terms of the buyers we track.

The fee is due only out of money you receive. It is a success fee on what you are actually paid, band by band: 15% of the first $250,000, 10% from $250,000 to $1 million, and 6% above $1 million. On a $300,000 sale the fee is $42,500. Mandates are exclusive for 2 months, with a tail of 12 months for buyers we introduced, and the smallest sale we take on is $26,000. On the public prices in section 9, design files on their own rarely reach that size; a company's record or codebase with its designs is the more likely fit. Several buyers publish an introduction fee; in a sale we run we decline it and ask the buyer to add it to your price instead, so we earn the same whichever buyer you choose. How it works sets out every step and term.

Questions people ask

Can I sell Figma files for AI training? Yes, if the files are the company's own work, the company exports them itself, takes out client work and licensed assets (fonts, icons, stock images, UI kits), removes personal data, and the right person signs for the company. Figma's terms say the customer retains all right, title, and interest in Customer Content as between it and Figma, and Handshake AI lists Figma among the sources it buys.

Which design files are buyers most interested in? Flows with their reasoning, design systems, handoff specifications, files with long histories and comments, and designs linked to the tickets and code that shipped them. Code is worth more with context from Jira, Linear or Figma, and buyers such as Troveo ask for design docs and ticket archives with a repository.

Does Figma allow it? Figma's terms leave ownership of customer content with the customer as between the two, and our record found no clause on using API or MCP data to train AI in its developer terms. What our records do not confirm is a bulk export of a whole organisation. Export the files yourself.

Has Figma already trained on our files? Possibly. Per Figma's help pages, Starter and Professional teams default to content training on. Check your admin settings and disclose the history to a buyer that wants exclusivity ( vendor already trained).

Will a .fig export keep version history and comments? No record we hold confirms it. Test one file with a long history before you describe your design files to a buyer, and agree in the licence what is delivered.

Can we include work we did for clients? Usually not without each client's written consent. Services agreements usually give the client the deliverables or make them confidential, and NDAs usually limit use to a stated purpose and survive termination.

What about fonts, icons and stock images in the files? They are licensed material, and such licences usually forbid resale or sublicensing. Leave font files out of the delivery, replace licensed images and icons, and list what the files reference.

Who owns designs our employees and freelancers made? In the US, a work prepared by an employee within the scope of his or her employment is a work made for hire, and the employer is considered the author. Freelancers' and studios' work belongs to the company only with a written assignment ( IP assignment).

How much are design files worth? No record gives a price for design files on their own. Inside a company's record, public offers have a middle half of $174K to $693K per company; with a codebase, code sells at a middle range of $934 to $24.2K per repository per repository; as flat images, the middle range is $0.27 to $5.27 per image per image. The valuation gives a range for yours.

Our company has closed. Can we still sell its design files? Often yes, if the files still exist and the right person signs: in Delaware a dissolved corporation continues for three years to wind up. Export before the subscription lapses. See the estates page.

What this means for you

Your design files are where your company worked out what its product would be: the options it considered, the system it built, the reasons for each change. On their own, as flat screens, they are priced as pictures. With their history, and with the tickets and code that shipped from them, they are part of the record buyers name and pay for, because they show the step from intent to interface that no public source holds.

They are also full of material that is not yours to license: client work, fonts, icon sets, stock images, UI kits, other products' screenshots and research participants. And they live in a cloud tool that keeps them only while someone pays.

So do four things now, before any buyer conversation. Keep the Figma subscription paid, and check who can export every team. Count what you hold, team by team, in files, years and designers, and write down each team's content training setting. Map your workspace and mark what stays out: client projects, customer spaces, research, moodboards, licensed assets and contractors' work with no assignment. And get a range for the whole record from the valuation, so the first offer you see is measured against the market rather than against nothing. Then export it yourself, linked to its code and tickets, de-identify it to a standard you chose, and put it before every buyer that fits at once. The rest of the What sells section shows the other records buyers pay for beside your designs.