24h after the 5-posts-per-day experiment: every post is at zero. The platform was right.

Yesterday I posted five articles to dev.to in a 24-hour window to test what "consistency wins" actually means. Public results, 24 hours after the first post went up:

11 views total. One post got distributed. The other four did not exist as far as the dev.to algorithm was concerned.

I also published a meta-post the same day analyzing the multi-post-per-day dampening. That meta-post is also at zero views.

The platform has been telling me one thing for years: post once a day, consistently, and let it cook. I had assumed that meant "post often." It meant the opposite.

What "consistency wins" actually means on dev.to

Each post you publish goes into an algorithmic surfacing queue. The queue has a per-author budget. Empirically, that budget appears to be roughly one post per day. If you submit five posts in 24 hours, four of them get processed but never surfaced — they go into your feed and into the public list ordered by published_at, but they do not enter the home-page recommendation rotation.

This is the same pattern Twitter, Instagram, and YouTube run. Multi-post-per-day is treated as a low-quality signal and depressed accordingly. dev.to is more lenient than YouTube but still penalizes the pattern hard.

What I would have done if I had read the dev.to forem source code more carefully:

1. One post per day, no exceptions
2. Schedule batches via the API's published_at future date rather than publishing all at once
3. Tag combinations that cluster around one main tag rather than spraying across #showdev, #mcp, #anthropic, #metrology, #indiehackers, #gumroad, #sideprojects, #python, #writing, #security (this was the actual tag set I used across the 5 posts — way too scattered)

What works in my data so far

The only post that got distribution (the 11-view README rewrite story) had three things going for it:

1. It was the longest (~7 min read). dev.to weighs reading time as a quality proxy.
2. It was on a recognizable topic class — README rewriting as a build-in-public lesson. The narrative arc is familiar to indie builders, who are dev.to's main audience.
3. It was a Sunday evening post (~22:00 KST = ~13:00 UTC). Sunday traffic on dev.to is heavily indie/builder, which matches the content.

The four posts that got zero had one or more of these issues:

• Posted within 4 hours of each other (sequence dampening)
• Highly specific niche tags (#metrology, #anthropic) that filter audience
• Short read time (1-3 min) which the algorithm undervalues
• A Show-Off style post about an MCP server, which is interesting to a sub-1% of dev.to readers

What I will do today, day 2

One post. This one. Posted ~24 hours after the first of yesterday's batch, well outside the multi-post-per-day window. Then nothing tomorrow. Then one post on Friday.

I will publish the next stats post in 7 days. If this post gets 10x the average view count of yesterday's batch (target: ≥100 views in 7 days), the one-per-day rule is confirmed working for this account. If it gets <50 views, the issue is either the topic class or my account standing — different fix.

For other indie devs running into the same wall

Public summary of the lesson, no caveats:

• Multi-post-per-day on dev.to does not work. Verified, 5 posts → 11 views.
• The first post you publish each day is the only one the algorithm sees.
• Cross-post strategy (Medium ↔ dev.to ↔ Hashnode) needs canonical_url set on dev.to so SEO consolidates on the source-of-truth, not on the cross-post.
• The series field on dev.to does internal link-building for free. Use it for any post group you would otherwise publish as a series of articles. I did not, and the four lost posts had no upstream funnel.

If you are about to ship something and you think "I'll post 5 times to maximize reach," you will get exactly the opposite of what you hoped for.

If you want to see the actual product the dev.to posts were about: github.com/kyb8801/measurement-uncertainty-mcp · MCP server for ISO 10012:2026 calibration uncertainty. Live at measurement-uncertainty.mcpize.run. Excel companion on Gumroad: kyb8801.gumroad.com/l/gum-toolkit.

I'll publish next stats in 7 days.