Notes19 Aug 2026Supply

The expert supply problem

The people you most want writing training data are, almost by definition, the people least available to write it.

Here is the structural problem with expert data, stated plainly. The practitioners whose judgment is most worth capturing are senior, well paid, busy, and bound by employment agreements. They have no financial need for side income and no obvious reason to spend a Saturday writing down how they actually work.

Every platform in this space eventually collides with that fact. Most of them respond by quietly redefining "expert" downward until supply becomes easy — recent graduates, adjacent-field generalists, people with the credential but not the practice. The dataset still says "written by finance professionals." It is just no longer true in the way that mattered.

What doesn't work

We have watched several approaches fail, including some of our own.

Paying more, alone. Rate is necessary and it is not sufficient. Above a certain point you are competing against a senior professional's leisure time, not their hourly rate, and leisure time does not have a price that scales linearly. Doubling the rate does not double the supply of MDs willing to do piecework.

Appealing to the mission. Some people genuinely care about how these systems get built. Most reasonably want to know what it pays and how long it takes. Mission framing recruits enthusiasts, and enthusiasts are not evenly distributed across the domains you need.

Volume incentives. The moment you pay for throughput you have told your most careful contributors that care is uncompensated. They respond exactly as you would.

What does

Three things move senior practitioners, and none of them is the one people expect.

Respecting their time in the design, not the marketing. A task that takes ninety minutes and states so up front is more attractive than a vaguely-scoped one that pays more. Practitioners are optimising for predictability, because their scarce resource is a known block of uninterrupted time, not money.

Showing the bar before they start. The single most common piece of feedback we get is about seeing the checks in the brief. Professionals are entirely comfortable being held to a standard. What they will not tolerate is being graded against a rubric they were not shown, by someone less qualified than they are. Hidden rubrics do not just annoy contributors — they select against exactly the people whose standards are highest.

Making rejection actionable. A rejection that names the failing check reads as a professional exchange. A rejection that says "quality issue" reads as an insult from an anonymous reviewer, and it is the fastest way to lose a good contributor permanently. We have never had someone leave over a rejection that explained itself.

Professionals will accept a hard standard. They will not accept an unstated one.

The conflict question

The objection that comes up before rate ever does: will this get me in trouble at work?

It is a fair question and it deserves a structural answer rather than a reassuring one. Tasks have to be built so that nobody is asked to reproduce their employer's proprietary material, touch their employer's systems, or disclose anything confidential — constructed scenarios and public sources, by design, not by policy. Records carry a credential class rather than a name. NDAs run before any brief is sent.

Even then the right answer to "is this allowed?" is: check your own employment agreement, because we cannot make that call for you. Vendors who wave the question away are the ones storing up a problem.

Why this is the moat

It is tempting to think the hard part of this business is the platform. The platform is genuinely hard, and it is also the part a competent team can rebuild in a year.

What is hard to rebuild is a bench of senior practitioners who have done twenty tasks, know the standard, trust the rejection loop, and answer the email. That accumulates slowly, entirely through conduct, and it evaporates the moment you treat it as a funnel. Which is why the supply side is not a recruiting function here. It is the product.

Think you'd be good at this?

Tell us what you do and where you do it. We read every application ourselves.