Original data: the one thing that cannot be summarised from elsewhere

Consider what happens to a well-written general explainer. It competes with an unlimited supply of equally competent explanations, and it can be paraphrased completely. Now consider a page reporting what happened when a specific thing was measured on a specific system. It cannot be paraphrased away, because the fact originates there — anything restating it has to attribute it.

Why this advantage does not erode

Where a small organisation finds original data

The usual objection is that original research requires a research budget. It does not. It requires noticing that you are already generating data nobody has written down.

• Your own system, measured. Bundle sizes before and after a change, build times, query latencies, the actual cost of a feature per thousand operations. Numbers from one real system, presented as exactly that
• A structured comparison you needed anyway. If you evaluated four tools before choosing one, the comparison is a document. Publishing it costs the writing, and the evaluation was already done
• Aggregated operational data. Patterns across the things you operate, with anything identifying removed — how often a category of failure occurs, what a typical configuration looks like
• A survey of a community you belong to. Fifty honest responses from practitioners is a real finding if you report the sample size plainly
• A reproducible test. Build the test, publish the method and the harness, and invite disagreement. Method plus results is more citable than results alone
• Documentation of behaviour nobody documented. Not a number, and often the most valuable thing on this list, because it exists nowhere else at all

The first item is the one most teams overlook. A performance figure from your own production system, honestly labelled as one system's result, is a real data point. It is not a general claim, and it should not be presented as one — but a specific measured number from a named context is more citable than a confident generality.

Publishing it so it can be used

A finding buried in the ninth paragraph of a narrative is a finding nobody can extract. The reporting structure matters as much as the work.

1. 01State the finding first, in one sentence with the number in it, before any methodology.
2. 02State the sample and the context immediately after. One system, four tools, fifty respondents — whatever it actually was.
3. 03Give the method in enough detail to be repeated, including what you did not control for.
4. 04Publish the data where you can. A table beats a chart for extraction, and a downloadable dataset invites reuse that produces further citations.
5. 05Date it, and say when it was measured. A number without a date is unusable within a year.
6. 06State what it does not show. The limits are part of the finding.

Finding first, qualified immediately:

  Dropping the animation library cut first-load JavaScript by 47KB
  gzipped, from 238KB to 191KB, on this site's production build in
  September 2026.

  Measured on one site: a Next.js 16 App Router application with 63
  routes. The library was carried for three interactions; those are
  now CSS keyframes plus a 25-line hook. Figures are gzipped
  first-load JS for the route, from the production build output.

  What this does not show: that the library is unnecessary in
  general. An application using its layout animation or gesture
  handling would not get this result.

The number is extractable. The context prevents it being cited as a
claim about the library in general, which protects you from being
quoted saying something you did not say.

The integrity requirements are not optional

The entire value of original data is that it is true. A fabricated or quietly flattering number destroys the asset it was meant to create, and unlike most content mistakes it is discoverable by anyone who repeats the work.

• Report the result you got, including when it contradicts what you expected or what you sell
• Never round in the direction that helps you, and never present a best case as a typical one
• State the sample size where it is small, prominently, rather than in a footnote
• Remove anything identifying before publishing operational data, and get permission where the data is a customer's
• Correct it publicly if it turns out to be wrong, and leave the correction visible

The customer-data point is a hard constraint rather than an etiquette one. Aggregate figures derived from data you hold on behalf of someone else need their agreement and need to be genuinely non-identifying — and under data-protection regimes including India's DPDP Act, publishing them without both is a compliance problem, not a judgement call.

Cadence: one good finding a quarter

This is not a content-volume strategy and it does not want to be run as one. One properly conducted, honestly reported measurement per quarter accumulates into something a competitor cannot assemble by writing faster.

• Keep a running list of questions you wished you had data for; most are answerable with work you are already doing
• Re-run a previous measurement a year later — the comparison is a second finding, and trend data is more citable than a snapshot
• Link every general article to the relevant measurement, so the cluster has facts underneath the explanation
• Resist the urge to publish a weak finding on schedule; a bad number is worse than no number

The strategic point is simple enough to state in a sentence. Anything you can write about a well-documented topic, a model can already write. Anything you measured, it cannot — and that is the only part of your content nobody can generate their way past.