I finally opened the dev.to analytics tab. Here's what 7 days of writing actually looks like.
| Metric (last 7 days) | Number |
|---|---|
| Readers | 184 |
| Average read time | 3:21 |
| Reactions | 1 (from 1 unique user) |
| Comments | 2 |
| Bookmarks | 0 |
| New followers | 0 |
| dev.to internal algorithm traffic | 2 views |
| bing.com SEO traffic | 30 views |
| External referrers | 152 views |
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
Reduces dev.to publishing cadence to a respectable signal-pace — 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 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:
https://gist.github.com/foxck016077/18621168173229819e367fa71a6144ab
The Actor itself: https://apify.com/foxck/gmail-inbox-intel (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: https://github.com/foxck016077/apify-gmail-inbox-intel/discussions/17
Top comments (0)