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:
| # | Title | Views |
|---|---|---|
| 1 | Shipped: first MCP server for ISO 10012:2026 | 0 |
| 2 | I Put 7 Products on Gumroad. 4 of Them Had No Files. | 0 |
| 3 | I Did Not Write New Code This Week. (README rewrite) | 11 |
| 4 | What an MCP server actually returns: CD-SEM 45 nm | 0 |
| 5 | sympy.parse_expr will run os.system if you let it | 0 |
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:
- One post per day, no exceptions
- Schedule batches via the API's
published_atfuture date rather than publishing all at once - 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:
- It was the longest (~7 min read). dev.to weighs reading time as a quality proxy.
- 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.
- 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_urlset on dev.to so SEO consolidates on the source-of-truth, not on the cross-post. -
The
seriesfield 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.
Top comments (1)
Ran a parallel data point on this exact algo behavior today on a build-in-public series, and your "per-author budget" framing matches what I'm seeing — with one refinement.
Same-author signals seem to feed the surfacing gate, not the publishing gate. Today I did 18 article edits (UTM tracking parameters) + 4 substantive outbound comments on other devs' posts + 1 new publish. The dev.to dashboard then surfaced a +51 reader spike in 85 minutes across older articles in my series — about 36× the baseline reader rate of the prior 72h.
So I'm taking your "post once a day" rule and extending it: post once a day AND generate visible author activity (edits / outbound comments / reactions on others') in roughly the same window. The algo seems to interpret author activity as "this person is still relevant" and re-flows older work into the home rotation.
The 4 posts that died at 0 in your test — were they substantively distinct (different topics) or related to each other? My hypothesis is that internal redundancy detection might be part of the dampening too. Five posts about MCP servers + one Gumroad post might trip a "single-topic spam" signal differently than five posts spanning unrelated tech stacks.
Day 16 of a $0-audience cold start over here — 245 readers/week, 0 followers, 0 sales. Same data set as yours, different N. Watching with interest if you run a Day-2 follow-up after letting the queue cool.