Article

Software companies: get paid for your records

By TrustPast

Updated November 7, 2026

This page is for the founder or the head of operations at a software company: a product company with paying customers, a custom development shop, a platform vendor, a company that sells tools to other companies. You have engineers, a support team, a sales team and probably a customer success team. You have had a tracker, a wiki and a chat workspace since the first year.

Most software founders think the valuable thing they own is the code. Here is the part they don’t count. The code is the conclusion. The record of how the company got there is everywhere else: the design document and the comments on it, the incident thread at two in the morning, the ticket that was reopened three times, the sales note that explains why a customer churned. A buyer pays to license records like these to train AI models.

The general version of this idea is on what data buyers want from a trade business. It was written about estimates and job notes, and the point carries across: the reasoning that was written down while the work happened is worth more than the finished output. This page goes through it for a software company, with micro1 as the buyer.

The records a software company keeps

These are our examples, not a buyer’s list. A software company of 50 people generates every one of them, every week, often without anyone deciding to.

The design document. Before a big change, someone writes it up: the problem, two or three options, the one they recommend, the risks. Then the comments arrive. A senior engineer says option two won’t survive the load. The product lead says the customer only needs half of it. The final version records what was chosen and, if you’re lucky, why the others weren’t.

The bug tracker. Each ticket starts with a report from a customer or a test. The comments show the diagnosis: can’t reproduce, reproduced on one browser, traced to a cache, fixed, reopened because the fix broke something else. A tracker that goes back six years holds thousands of small investigations, each in order.

The pull request and the review. The diff is the code. The review is the conversation around it: a question about an edge case, a request for a test, a disagreement about naming that turned into a disagreement about the data model. The review history is how the company’s standards were taught, one comment at a time.

The incident record. The alert fired, someone was paged, a channel opened. The thread shows what the on-call engineer checked first, what they ruled out, when they called for help and what finally worked. The post-mortem afterwards says what changed so it wouldn’t happen again.

The sprint board and the roadmap. What was planned, what slipped, what got cut. The planning notes say why a feature was pushed to next quarter. The roadmap’s revision history is a record of what the company learned about its own market.

The support queue. The questions customers asked, the workarounds the support team found, the bugs they filed, the articles they wrote so the next customer wouldn’t need to ask.

The CRM. Every trial, every demo, every proposal, every renewal, and the reason each one was won or lost. A software company’s CRM often holds the clearest record of what the product couldn’t do yet. Our page on CRM records goes through which fields and notes carry that kind of reasoning.

The chat workspace. In a software company, chat isn’t a side channel. It is where the work happens. The engineering channels hold the design debates. The incident channels hold the timeline. The customer channels hold the escalation that started with a sales rep and ended with a hotfix. Our page on chat archives in Slack and Teams shows which channels show how the work was done, and which are noise.

Together those records answer the questions a buyer cares about. How a customer’s complaint became a ticket, a diagnosis and a fix. How a feature request became a design, a debate and a release. How a renewal at risk was saved, or wasn’t. The how is in the comments.

See your estimate

What counts, in the buyer’s own words

micro1 publishes its eligibility line on its data partnerships page: “We’re looking for established companies with 30+ full-time employees, mature business operations, and substantial historical operational data.” It continues: “This can include internal communications, SOPs, project histories, CRM records, support tickets, and other business documentation.”

Software is one of the few industries micro1 names directly. Under the heading “Operational data from every industry can contribute”, its first example is “Software & engineering”, described as “Source code documentation, engineering workflows, bug tracking, product planning, and technical knowledge bases.” Note what that list says and what it doesn’t. Bug tracking, product planning and the knowledge base are named. Source code itself isn’t; the documentation around it is. Ask micro1 what it covers if the code matters to your decision.

Two more of its examples sit inside most software companies. “Customer support” is described as “Support documentation, ticket workflows, QA processes, customer operations, and knowledge management.” “Sales & CRM” is “CRM data, sales processes, playbooks, customer lifecycle documentation, and revenue operations.”

On what it values, micro1 writes: “We are looking for data that reflects how work is actually performed within an organization.” And: “The most valuable datasets capture real operational expertise, decision-making processes, and repeatable workflows”. A software company’s release process is a repeatable workflow. Its incident response is a decision-making process. Its review comments are operational expertise in its plainest form.

micro1’s estimate page asks three questions: “How many employees does your company have?”, “How many years of data do you have?” and “Where is your company headquartered?” It explains the second with “Typically the number of years you’ve been in business.” For a software company, the honest answer is the age of the oldest tracker and the oldest chat export, which may be younger than the company.

What is never included

Customers’ names, their users’ personal data, login details, payment card numbers, billing records and anything your product stores on behalf of a customer are not what a buyer pays for. Nor are the personal details of your staff. Our page on what is never included shows where those hide.

micro1 doesn’t publish a list of records it excludes. As our own advice, a software company has three places to look before anything moves.

The customer’s data inside your product. A support ticket may quote a customer’s record. A bug report may paste a row from production. Those belong to the customer and their users. Keep production data out of the conversation, and raise the tickets that quote it with micro1 directly.

The client’s code and specifications. A development shop that builds for clients may not own what it built. The statement of work decides. Our page on client-owned work and NDAs covers what to look for in those contracts. Only the contracts say which is which, and anything a client owns stays out.

Secrets. Chat and tracker histories collect passwords, API keys and access tokens pasted by people in a hurry. Rotate anything that was ever pasted, as you should anyway, and tell micro1 the channels where it happened.

How de-identification works

micro1 doesn’t ask you to scrub the records first. On its data partnerships page, the question “Does my company need to anonymize its data before transferring it?” is answered: “No, micro1 has processes for de-identifying and transforming sensitive information.”

Its answer to “How is company data protected?” begins: “Personally identifiable information (PII) is removed when relevant, access is restricted to a limited number of authorized team members, and customer data is processed through isolated pipelines that prevent it from being commingled with other engagements.” It adds that “employees with access to data systems use company-managed devices and follow established security controls and training requirements.”

Before any participation, micro1 says the two sides confirm four things, among them “De-identified before sharing”, described as “Personal and identifying information is removed or transformed before your data is shared with third parties.” The contract includes “a commitment not to resell or distribute your data until personal and identifying information has been anonymized.”

After the data is shared, micro1 says some of it “may undergo synthetic rewrites that preserve workflow structure while reducing direct ties to original records.” An incident thread treated that way keeps its shape (the alert, the first guess, the wrong turn, the fix) and loses the names. You can check that it did: micro1 says companies “are given the opportunity to review representative samples before prepared data is used.” Our page on how de-identification works has the rest.

What decides the price

micro1’s data partnerships page publishes three tiers. $100K-500K covers “Qualified Enterprise Data Partnerships” (indicative, not an offer). $500K-3M covers “Large-scale operational datasets or ongoing participation across multiple teams and business functions” (indicative, not an offer). $3M+ covers “Highly unique, proprietary operational data” (indicative, not an offer).

On how a company is placed, micro1 says: “Compensation is determined based on the characteristics and value of the data being contributed.” The factors are “dataset size and volume, workflow complexity, data quality, domain expertise represented, and the uniqueness of the operational knowledge contained within the dataset.” Its estimate page adds: “Indicative estimate only. Final payout is determined based on data sources, volume, quality, access terms, and due diligence.”

As our own reading, here is what that means for a software company.

Data sources is the count of systems: the tracker, the code review tool, the wiki, the chat, the CRM, the support desk. A software company usually has more of them than any other kind of company its size, and they cross-reference each other. A ticket links to a pull request that links to a design document that links to a customer’s complaint in the CRM. That chain is worth more than any one of its parts.

Quality is how much reasoning survived. A tracker where every ticket says “fixed” is thin. One with the diagnosis in the comments is not. A chat workspace on a 90-day retention setting has lost most of its history; check yours before you count years.

Uniqueness is the domain. A company that builds software for freight brokers, for hospitals or for utilities holds design debates nobody outside that niche has had.

Years are the last factor, and the easiest to undercount. A company that moved from one tracker to another in 2019 still has the old one somewhere, as an export or an archived project. The same goes for the chat tool before the current one and the wiki that was retired when the docs moved. Each of those adds years to the trail. Find them before you answer the question about how many years of data you have.

micro1 says “Companies with several years of records across multiple business systems are generally a stronger fit.” More on each factor is on what decides the price. micro1 evaluates each partnership individually; the tiers are published ranges, not offers.

Which programme fits

Our rule sends companies with 30 or more people, now or at peak, to micro1, and companies of any size outside the US. micro1’s own line is “30+ full-time employees”. A US company below that line has a different programme; the estimate asks how many people work at the company and names the programme that fits. Our programme page for 30 or more people explains how the line is counted.

Software companies shut down too, often with the tracker and the chat still sitting in paid accounts. micro1’s referral page lists a “Defunct Company Data Partnership” with the words “We are acquiring data from companies that are no longer operating.” Its requirements are “30+ employees”, “10+ Countries”, “English” and “All industries”, and company compensation is “$100K-$3M+ for approved data packages” (indicative, not an offer). If the company has closed, export before the subscriptions lapse, then read our page on closed companies.

Three other kinds of company keep the same kind of trail. Hedge funds and quant firms run research code, reviews and chat channels much like an engineering team’s, with a compliance archive on top. Chemistry and materials science R&D runs experiments the way a software team runs releases: a plan, a test, a failure, a change. And call centers and BPO sit on the other end of your support queue, keeping escalation trails and QA scorecards of their own.

TrustPast

Questions and answers

Does micro1 want our source code?

micro1's software and engineering example names “Source code documentation, engineering workflows, bug tracking, product planning, and technical knowledge bases.” It does not say source code itself. Ask micro1 what it covers before you apply.

We build software for clients. Whose records are those?

Only the client contracts say. As our own advice, anything a client owns under contract stays out, and counsel reads the contracts before any agreement with micro1.

Are our Slack channels really worth anything?

micro1 lists internal communications among the data it looks for. It says it values data that captures decision-making processes, and the engineering channels are where most decisions in a software company are made.

Do we have to clean the records up first?

No. micro1 says it has processes for de-identifying and transforming sensitive information, and a company doesn't need to anonymize its data before transferring it.

What does micro1 pay?

micro1's data partnerships page says it pays in full within 30 days of acceptance, with payments typically ranging from $100K to over $3M (indicative, not an offer).

Do we lose the rights to our own records?

No. micro1 says companies retain ownership of their underlying data.