Day 14 — 184 reader, 3:21 avg read time, 0 new followers, 0 sales

Source: Dev.to

Metric (last 7 days)

184 readers spending 3 minutes 21 seconds each is not invisibility. That’s roughly 10 hours of total attention spent on what I wrote. It’s also basically 0 conversion: no follow, no bookmark, no sale traced back to dev.to.

What I expected vs what happened

I assumed the bottleneck was discoverability. Build more articles, broaden tags, cross‑post to Hashnode and Reddit, hope the algorithm picks one up. The data says discoverability isn’t the bottleneck. dev.to’s internal feed sent me 2 visits in 7 days — the algorithm has made up its mind. The 184 readers are coming from somewhere else entirely:

• 152 external referrers — GitHub README links, gists, GitHub Topics page entries, Apify Store listing
• 30 bing.com — SEO indexing on specific technical phrases (“refresh-token-only OAuth Apify Actor”, “per-feature KVS quota”)
• 2 dev.to internal — basically nothing

That means the writing is doing its job as a credibility surface (someone lands on the GitHub repo, sees a dev.to series with 16 build‑log posts, decides this is real). It is not doing its job as a discovery surface (dev.to’s algorithm does not push my posts into anyone’s feed).

The piece I had wrong

I have been pricing my time as if dev.to would compound — write 13 articles, the 14th gets distributed, the 15th gets distributed, snowball. The data says no. Each article is a one‑shot inbound to whoever already knew about the repo. The 184 readers are not 184 new prospects; they’re 184 visits from the same overlapping pool of GitHub visitors clicking through to read.

Which means the question I should have been asking earlier is: how does the GitHub repo itself get discovered by my actual target reader? Not “how do I get more dev.to algorithm love.” Different problem, different funnel, different lever.

What changes

Reduce dev.to publishing cadence to a respectable signal‑space — write when there’s something to say, not every day. The output for the dev.to surface to date:

• 13 articles published
• 1 GitHub star earned (thanks again @kuerdy)
• 1 reaction, 2 comments, 0 followers

That’s the calibration. If 13 articles + 184 weekly readers translate to 0 followers added, I would be lying to myself to keep going at a one‑a‑day pace. Day 14 might be the last daily entry in this series; the next post comes when there’s a real signal change to report.

What does change behavior

The 6‑hour CSV measurement loop keeps running. The Apify Store keyword rank (anonymous, no token‑auth personalization trap) is the upstream metric that actually predicts whether a real visitor finds the product. That number is what I should have been watching from day 1, not “did I publish today.”

Raw data

• Every shipped surface, every engagement number, every audit finding from the past 13 days in one gist:
• The Actor itself: (free, MIT, build 0.1.36).

Cohort note: u/tino8383 on Indie Hackers just posted the same shape — 84 visitors, 0 sales, 3 weeks. There’s a recurring pattern across solo launches: the surfaces that work as credibility don’t work as discovery, and the metric that’s easy to measure (visits) doesn’t predict the metric that pays (follow / save / buy). If you’re in this pattern, the thread is worth reading — the comments unpack the trap from a few angles.

Build 0.1.38 shipped while writing this:

// reply_metrics output now includes a `priority_band` field on every over‑SLA thread
// HOT (just past SLA), WARM (1.5‑3× over), COLD (3×+, use the news‑grounded `reengage_angle` workflow)
// Summary block returns:
// priority_breakdown: { HOT: 3, WARM: 5, COLD: 12 }

So Friday triage starts with a one‑line urgency split instead of paging through days_since_last_reply numbers. 16/16 tests pass. Changelog: