Code is only part of what a software team produces. The issue that described the bug, the review comments that improved the fix, the release notes, and the incident timeline are the records that show how engineering decisions get made. Buyers building coding agents want that context around the code, not just the code.
No dataset needed to start. Buyers price from a one-page manifest; nothing leaves your systems until you sign.
Buyers building coding agents want the context around the code: the issue, the review comments, the incident, the release. Rights clarity on the code itself is the gating factor.
Every record type carries a weight in the estimator behind /estimate, and the weights are published so you can see the work. Engineering workflows sits at the upper half of the eight.
Indicative range observed across the market for single-company operational data licenses. Not a quote. Actual value depends on buyer demand, data quality, rights, and exclusivity.
Open the estimator →A fictional record, prepared the way a buyer would receive it. The workflow survives. The people, companies, and identifiers do not.
| Field | Your record | De-identified copy |
|---|---|---|
| Issue | #2214, Checkout total off by tax on split shipments | Issue 001, Checkout total off by tax on split shipments |
| Reporter | priya.n (Support), 2024-05-16 | user-11 (Support), 2024-Q2 |
| Assignee | dev.lucas | dev-03 |
| Review comment | @dev.lucas this recomputes tax per shipment but the discount is applied once at cart level, so the second shipment under-collects. See cart.ts:142. | @dev-03 this recomputes tax per shipment but the discount is applied once at cart level, so the second shipment under-collects. See cart.ts:142. |
| Outcome | Merged after 2 revisions, released in v4.8.1, 3 related tickets closed | Merged after 2 revisions, released in [version], 3 related tickets closed |
Fictional example for illustration. Names, companies, and identifiers are made up; no real record is shown. The signed license specifies the de-identification standard, who performs it, who verifies it, and the remedy if it is missed.
What gets removed, what gets excluded by rule, and what to confirm about your rights. Your counsel signs off on scope before any buyer sees it.
Developer names, emails, and handles are mapped to consistent fictional identities. Secrets, keys, and credentials are scanned for and removed.
Client-owned repositories, code under restrictive open-source licenses, and anything your counsel flags are excluded by rule.
Confirm contractor agreements assign IP to your company, and check customer contracts for clauses that treat custom code as the customer's property.
We help you build the manifest and we ask these questions, but we do not provide legal advice. Whether a specific set of records can be licensed is a decision for your counsel.
Not necessarily. Many deals cover issues, reviews, incidents, and release records with the code excluded or limited to the diffs under review. Where code is included, it is only code you own outright, and the license defines the field of use. You decide where the line sits.
Preparation includes a secrets scan across commits, tickets, and chat, and anything found is removed before a sample exists. If a scan finds live credentials, rotate them regardless of the deal.
Using open-source libraries does not. Licensing someone else's open-source code as if it were yours would. Your own repositories, with third-party dependencies excluded, are what goes in the manifest, and your counsel confirms the ownership of each one.
Seven questions. No dataset. First offer in 24 to 48 hours of a complete manifest.
Measured from a complete data manifest. A first offer is a process target, not a guarantee; buyers decide eligibility, price, and terms.