What is a data flywheel, and why isn't it enough for AI developers?

What does data flywheel mean?

A data flywheel is a loop in which using a product generates data, the data makes the product better, and the better product draws more use, which generates more data. Like a heavy flywheel, it is slow to start and hard to stop once it has momentum.

The idea comes from product strategy, where it explains why recommendation feeds and navigation apps improve faster the more they are used. In AI, it usually describes a deployed model whose ratings, corrections and accepted or rejected outputs feed its next round of training. One detail defines its reach: a flywheel only records what happens inside the product that runs it.

How does a data flywheel work?

Most flywheels turn through five stages.

1. Use: people work with the product, for example asking an assistant to draft a reply or accepting a suggested delivery route.
2. Capture: the product logs the input, the output and a quality signal such as a rating, an edit, an override or an abandoned session.
3. Learn: the team filters and labels those logs and uses them to retrain or tune the model.
4. Improve: the updated model gets better at the requests users bring most often.
5. Attract: better results bring more users and more usage, and the loop turns again.

Illustrative: a fictional dispatch app for plumbing contractors suggests which technician to send to each job. Every time a dispatcher overrides a suggestion, the app logs it, and after a year the model predicts dispatchers' choices well. What it has never seen is whether the leak was fixed on the first visit, why an invoice was disputed or why a customer cancelled a service plan. Those facts sit in the contractor's own job files, accounting system and email.

Data flywheel vs similar terms

A flywheel and a network effect often travel together but are different things: the first is about the product learning, the second about users gaining from one another. Licensed records sit outside both loops because they are the work itself rather than someone's interactions with a tool. Turning those records into training sets is a separate step, covered in what is data curation for AI.

Why isn't a flywheel enough for AI developers?

A developer's flywheel shows how people use the developer's own product, not how a business runs end to end. As AI shifts from answering questions to agents that complete multi-step work across email, CRM, finance and ticketing systems, that gap matters more.

Four limits stand out:

• It captures the request, not the result. The log holds the drafted proposal, not whether the deal was won three months later.
• It covers one tool, not the workflow. Real work moves across systems, approvals and people that never touch the developer's product.
• It is bounded by the developer's promises. FTC staff have stated that commitments not to use customer data for purposes such as training models are enforceable, whether they appear in privacy policies, terms of service, promotional materials or marketplaces. That post is staff guidance, not a rule, but data covered by such commitments cannot simply be fed back into the loop.
• It cannot start in a new field. A flywheel needs users before it produces anything, so a developer building an agent for freight brokerage or construction project controls has no loop to learn from yet.

Public text does not close the gap. Researchers at Epoch AI projected that, if current trends continue, language models will fully use the stock of human-generated public text between 2026 and 2032, a forecast they present with wide uncertainty. That pressure is one reason AI labs and data buyers license permissioned records of real work. The US angle is explained in why AI developers want data from US companies, and the market picture in how much AI developers spend on data.

This is general information, not legal, tax or financial advice.

What does this mean for companies with years of operating records?

The records a mid-sized company accumulates simply by operating, such as resolved tickets, won and lost bids, approved and rejected invoices and project post-mortems, are exactly what no developer's flywheel can produce. That is what makes them worth licensing, provided the company holds the rights and can export them.

When screening a company, separate two kinds of data:

A quick rule: if the best data a company can point to is its customers' usage logs, ask about rights before anything else. If it has years of its own operating records spread across many systems, it is worth a screen.

That screen is short. Look for a US company with 50+ full-time employees at peak (contractors excluded), several years of documented operations, the rights to license what it holds, and an owner, CEO, CFO or other authorized representative ready to sponsor the process. The company fit checker gives a preliminary, non-binding read without asking for contact details.

Related terms

• Compute-to-data: buyers run training or evaluation inside a controlled environment instead of receiving copies of the records.
• AI partnership vs data licensing: when a company should license records rather than co-develop a product with an AI developer.

Next step

If a client or portfolio company has years of its own operating records, introduce it. You share your referral link or submit the company; SourceX qualifies it, the company completes a data inventory, and price and terms are agreed before buyers review. You never touch the data, and how it works walks through each stage.

Partners earn 25% of the eligible platform fees SourceX actually collects from the referred company's licensing deals, capped at $100,000 per referred company, and rewards become payable only after the buyer pays and SourceX receives its fee. Rewards are not guaranteed.

Register as a partner to get your referral link, or send a company owner straight to sourcex.si/apply.