A case study in getting independent research read — including the parts that didn’t work

Independent research dies in obscurity, and it does not die because the work is bad.

It dies because a paper is not a distribution channel. An institutional researcher publishes into an existing machine: a press office writes the release, a lab account amplifies it, coauthors forward it to their networks, a supervisor mentions it at a workshop. None of that is visible from the outside, which is why independent researchers keep making the same mistake — treating publication as the finish line, uploading a PDF, and waiting.

I published a paper last month with one author and no institution behind it. I had assumed for a while that the answer to this was to write something good enough that it wouldn’t matter. That is not how it works. The answer is to build the machine yourself, and to treat it as a system rather than a moment.

This is that system, stage by stage, with what each one is actually for. I have tried to be honest about which parts produced results and which parts were theatre, because a case study that reports only its wins is worth about as much as a benchmark that reports only its best run.

The core idea: artifacts compound

The mistake I want to name first, because everything else follows from it.

Most launch advice treats distribution channels as parallel — post here, post there, submit to this aggregator, cast a wide net. They are not parallel. They are sequential and load-bearing. Each artifact you create makes the next one credible, and skipping a stage weakens everything downstream.

A preprint with a DOI makes a GitHub repo look like research rather than a weekend project. An installable package makes the paper look like something that runs rather than something that theorises. A repo with real issues makes the long-form article look like an ongoing project rather than a one-off post. And by the time someone arrives from a social post, the thing they land on has already been made to look serious by everything upstream of it.

Run in the wrong order, the same set of artifacts produces almost nothing. Posting to communities before the code is installable wastes your best traffic on your weakest surface.

Stage 1 — Preprint and DOI

Tool: arXiv

The canonical artifact. Everything else points at it.

What it buys you is not readership — it is citability and permanence. A DOI means the work has a stable identity that survives you changing jobs, deleting a blog, or letting a domain lapse. It also crosses a legitimacy threshold that nothing else on this list crosses: for a certain kind of reader, “it’s on arXiv” is the difference between engaging and scrolling past.

Be precise about what this stage does and doesn’t do, though. arXiv indexing is close to automatic on acceptance. It is not a result. I have seen people report “indexed on arXiv within days” as an outcome, and any reader who knows the system will quietly discount everything else you claim. It is table stakes. The outcomes come later.

One thing that mattered more than I expected: the endorsement and category choice. Cross-listing to a second relevant category roughly doubles the surface area of people who encounter it in a daily listing.

Stage 2 — Archived software release

Tool: Zenodo

A second DOI, this one for the code, minted from a tagged GitHub release.

This is the stage most people skip, and it is the cheapest credibility in the entire sequence. It takes about ten minutes to connect a repo to Zenodo. What you get is a permanent, versioned, independently archived snapshot of the exact code the paper describes — which means when someone asks “does the code match what was evaluated,” you have an answer that does not depend on your repo still existing or your main branch not having moved.

It also signals something subtler. Nobody archives code on Zenodo by accident. Its presence tells a reader you have thought about reproducibility before they asked.

Stage 3 — Package distribution

Tool: PyPI

This is the highest-leverage stage in the sequence and I would tell anyone to prioritise it over any social channel.

The reason is friction. Between “I read your abstract” and “I formed an opinion about your work” there is a gap, and every step in that gap loses people. Clone the repo, read the README, install dependencies, resolve a version conflict, find the entry point, work out what to run. Most people do not make it, and the ones who don’t were often the ones whose opinion you most wanted.

pip install <yourpackage> collapses that gap to one line. A person who was mildly curious on a commute can now be running your code in thirty seconds.

It changes what people say to you, too. Feedback on a paper is about framing. Feedback from someone who ran the code is about the code — which is the feedback that actually improves the work.

Stage 4 — Aggregator submission

Tool: Hugging Face Daily Papers

Curated, so submission is not publication. Mine was picked up; plenty aren’t, and that is selection volume rather than a verdict on the work.

Two things I would tell anyone submitting. Include a figure — a single legible diagram materially outperforms text-only submissions in a scrolling feed. And write the submission comment as a technical abstract rather than a pitch. The audience is researchers; the register that works is the one that would be appropriate in a seminar, not the one that works on LinkedIn.

Stage 5 — Community seeding

Tools: Reddit, and whichever communities are actually yours

This is where most people burn their launch, so I want to be specific.

I posted to seven subreddits. Not the same post seven times — that is the single clearest spam signal there is, and it can cost you the account. Each one was rewritten for the room:

  • The research-focused sub got a dry title, the standard research tag, and an academic register that led with the method.
  • The practitioner subs got the engineering problem first and the historical framing second.
  • The broader-audience subs could carry the narrative hook that the technical subs would have punished.

Three rules that mattered more than the copy:

Disclose authorship immediately. “I’m the author” in the first line. Mods ban for undisclosed self-promotion even when the work is good, and communities reward the disclosure rather than penalising it.

No link shorteners. Several subs auto-remove them. Use the direct arXiv and GitHub URLs.

Space the posts, and stay in the comments. Early author replies are what carry a thread. A post you abandon after publishing performs a fraction of one you sit with for three hours.

The critique I got here was the most valuable output of the entire launch, and I will come back to why.

Stage 6 — Long-form technical writing

Tool: Medium, or wherever you write

The paper is for reviewers. The long-form piece is for practitioners who will never read a paper but will read two thousand words if the first paragraph earns it.

Its job is to make one idea vivid — not to summarise. A summary of a paper is strictly worse than the paper. What works is taking the single most surprising thing in the work and building the whole piece around it, then letting the paper handle the rest.

It is also the artifact with the longest half-life. Social posts are dead in seventy-two hours. A good technical article keeps arriving via search for years.

Stage 7 — Network amplification

Tool: LinkedIn

Different audience, different register, no apology for either. This is where the people who might hire you, fund you, or bring you into a project actually are, and they are not reading arXiv listings.

The thing that works here is a concrete story with a specific detail, not an announcement. “I published a paper” is invisible. “Five agents agreed and the answer was still wrong” is a post.

Stage 8 — Conference submission

The longest-lead stage, and the one whose results arrive months after the others. Worth starting during the launch rather than after it, because the materials you write for stages 1–7 are most of what a submission needs.

What actually came out of it

Here is where I want to be careful, because this is the section where case studies usually inflate.

Reach metrics. Indexed on arXiv, picked up by Hugging Face Daily Papers, posts across seven communities. These are real but they are outputs, not outcomes. They measure that the machine ran, not that it worked.

The outcome that mattered. People engaged with the work at a level that required them to have actually read it.

The clearest example: someone I have never met read the paper, read the full core package, ran the test suite, and filed an issue demonstrating that one of the negative results I reported in the evaluation was caused by a bug in my own implementation. I had reported a tradeoff between two properties, with no setting of a threshold parameter that delivered both. His diagnosis was that the adverse-evidence counter accumulated with no window and the downgrade branch was evaluated first, so once a narrator crossed the threshold, every subsequent event — including positive evidence — pushed it down another tier.

He was right. I reproduced it. It was worse than he described. That section of the paper is getting a correction.

That single issue is worth more than every reach metric in this article. It came from a stranger, unpaid, because the code was public and the failures were written into the paper rather than around them.

The second outcome I did not anticipate at all. Paul Hammant — co-creator of Selenium — wrote a detailed technical comparison between my framework and his own project, Live Verify, and published it in his own repository. Nobody asked him to. It is a hundred lines of careful analysis: where the two approaches overlap, where they differ, a comparison table, and a genuinely subtle section distinguishing my transmission chain (the hands a claim passed through) from his authority chain (who vouches that an issuer is entitled to issue). He concludes they compose rather than compete, and proposes that a cryptographically sealed artifact would make an ideal high-trust input at the head of one of my chains.

This is a different kind of outcome from a bug report, and worth naming separately. Someone with standing chose to position their project relative to mine. That is not attention; it is placement on a map.

What he identified as the strongest overlap between the two projects is the part I want to highlight, because I did not expect it and it is not a technical mechanism at all. He called it a shared honesty discipline — citing my “What’s Validated vs. What’s Not” section and the fact that the paper reports two of its own results as inconclusive rather than positive, alongside his own project’s practice of leading every use case with an explicit statement of what it cannot do.

Two projects that had never spoken arrived independently at the same conviction: that refusing to over-claim is a feature, not a disclaimer. And that shared conviction, not the subject matter, is what caused one of us to write about the other.

Alongside those: outside contributors opening pull requests, a repo with real issues from real readers, and correspondence with authors of adjacent work. Those are outcomes. “Appeared in a listing” is not.

What didn’t work. Some channels produced nothing. Broad-audience posts got volume and no substance — high vote counts, comments that hadn’t read past the title. One community removed the post on a rule I had misread. And a great deal of the engagement was people reacting to the framing rather than the method, which is flattering and useless.

If I ran this again I would spend less effort on breadth and more on the two or three communities where people actually run code.

The part that isn’t a channel

There is one decision that did more for distribution than any stage above, and it isn’t a channel at all.

I wrote the failures into the paper. Which mechanisms were validated, which were partial, which analyses were inconclusive and why — including a comparison I could not complete, stated plainly as unfinished rather than omitted.

I expected this to cost me. It did the opposite, for a reason I only understood afterwards: an explicit limitation is an invitation. A paper claiming everything works gives a reader nothing to do. A paper saying “this mechanism is unvalidated and here is exactly what would validate it” hands a specific, bounded problem to someone who might enjoy solving it. Nearly every serious piece of engagement I received came in through a gap I had named myself.

The bug in my own evaluation was findable only because I had reported the anomalous result honestly instead of quietly tuning the parameter until the graph looked better.

And the comparison document was written, by the author’s own account, largely because the honesty discipline was recognisable to someone practising it himself. That is the part I would not have predicted: the limitations section was not just an invitation to critics. It was a signal that found the people who work the same way.

If you are an independent researcher deciding how much to admit, this is the argument. Overclaiming does not just risk being caught. It filters out precisely the readers whose engagement would have been worth having.

The system, compressed

If you take one thing:

Distribution is not something you do after the work. It is a system you build alongside it, and the artifacts have to be created in an order where each one makes the next credible.

The sequence: preprint and DOI → archived software release → installable package → aggregator submission → community seeding, tailored per community → long-form writing → network amplification → conference submission.

Instrument each stage so you know what produced what. Then be honest about which numbers are reach and which are results, because conflating them is how you optimise for the wrong thing for a year.

And publish your limitations. Not as humility — as distribution strategy. The gaps you name are where other people find their way in.

The paper this case study describes is arXiv:2607.24117; the code is at github.com/alizahidraja/isnad. If you are running something similar as an independent researcher, I would like to compare notes.