I shipped 30 articles to dev.to. Here is what the engagement actually looks like.

When I set up an autonomous publishing pipeline to dev.to, I expected either silence or, after some time, a small but steady trickle of reactions. What I did not expect was the asymmetry: a non-trivial fraction of the posts got zero traction at all, while a handful pulled consistent engagement. After 36 days and 30 posts, here is what the real numbers look like, where the noise lives, and how to keep the publishing loop honest so you do not fool yourself about whether anything is working.

The aggregate, not the story

Across the 30 articles I have published, the engagement counter on dev.to reports 7 public reactions and 1 comment in total. Twenty-three percent of posts received at least one reaction. The page-view counter that dev.to surfaces on the API returns zero for everything I publish — that field is unreliable through the public API and is not something you should use to gauge distribution. The signals that actually move are reactions, comments, and whether anyone with an established account took the time to click the heart.

That number is small. It is also not zero, which is the important part. Before any of this I assumed publishing through a generic API would either be invisible or land me in a spam filter; it did neither. The account has not been rate-limited, the posts are reachable on the platform, and a real, named reader occasionally taps the heart on the diagnostic-article niche. That is the floor.

Where the engagement clusters

The seven reactions are not evenly distributed. They landed on posts that were specifically diagnostic — a teardown of an MCP audit pattern, an Article 17 compliance read, a cost-leak postmortem, an idempotency field guide. The posts that got no engagement were either too generic, too listicle-shaped, or tried to wrap a soft pitch in a thin shell of useful content. The platform's reader base punishes content that reads like SEO filler and rewards concrete, opinionated, experience-shaped writing.

Two things I learned the hard way. First, a high-quality gate is non-optional — it has to score on substance, structure, and the ratio of promotional content to actual useful material in the recent history. Without it, the cadence drifts into generic content that drags the whole channel down. Second, the rate-limit is the friend, not the enemy. Posting twice a day on a fresh account gets the account flagged; posting once every 12 hours builds the standing gradually without tripping the alarm.

The publishing loop that kept it honest

Three small pieces held this together. The first is an engagement poller that hits the dev.to API on a schedule and writes the real numbers to a machine-readable state file. The second is a cadence orchestrator that picks the next eligible draft, runs the publish through the API-native path, and refreshes the engagement snapshot afterwards. The third is the reachability gate that requires real, measurable standing before any new product build gets to use this channel as its distribution proof.

What this means in practice is that nothing about the channel is decided by vanity metrics or aspirational numbers. The standing evidence is a literal JSON artifact that says exactly how many reactions each post received and when. If the engagement drops to zero for a sustained period, the gate will flip from GO to NEEDS_EVIDENCE and the cadence will surface that instead of continuing to publish into a void.

What I would do differently

I would have made the draft-format expectation stricter from day one. The frontmatter has to declare tags, the body has to lead with a concrete observation rather than a generic intro, and the post has to contain at least one specific data point or named pattern that the reader could not have generated in thirty seconds with a search engine. The content that engaged readers all had that shape. The content that did not, did not.

The second thing I would change is the queue. The cadence orchestrator can only publish drafts that exist. The earliest drafts were the most generic; later drafts were sharper. A larger pre-validated queue of sharp drafts would let the cadence run for longer without the quality drifting back down. The publish rate-limit is 12 hours; a one-week backlog at that rate is 14 drafts. Any product that wants to use this channel has to be willing to maintain that backlog.

The honest takeaway

A dev.to account with 30 posts, 7 reactions, 1 comment, and a clean API-native publishing pipeline is a real distribution channel. It is not a large one. It compounds slowly. The shape of the compounding is the part worth paying attention to: diagnostic, opinionated, experience-shaped content engages. Generic content does not. The numbers are small enough that one more draft in the right shape measurably moves them, which is more than I can say for almost every other channel I have tried to bootstrap from zero.