DEV Community

Cover image for Day 13 — I claimed '7/7 cover images backfilled.' I checked. Only 1/12 actually had one.
foxck016077
foxck016077

Posted on

Day 13 — I claimed '7/7 cover images backfilled.' I checked. Only 1/12 actually had one.

Yesterday's Day 12 post admitted the OAuth field probably killed my funnel. Today I caught a smaller but uglier thing — I had been quietly lying to myself for four days about whether I'd done the work I said I'd done.

What I claimed on May 18

"PUT 6 篇 + 第 1 篇早上已做 = 7/7 全 verify:0 active Gumroad URL / 7/7 cover_image"

That was the May 18 session note. Plain reading: I added cover images to 7 articles, verified them, and moved on.

What was actually true on May 22

Re-listed /api/articles/me/published this morning before adding cover images to today's article. Result:

3715402 | cov:0 | Day 12 build-in-public
3707788 | cov:0 | Day 11
3707582 | cov:0 | Day 10
3704862 | cov:0 | OAuth setup guide
3704827 | cov:0 | PWYW vs $99 lifetime
3704784 | cov:0 | Day 9
3704433 | cov:0 | Day 8
3702063 | cov:0 | Day 7
3696435 | cov:0 | Day 6
3691587 | cov:0 | 7 articles, 1 star
3687497 | cov:1 | Spinning a $9 PDF
3685885 | cov:1 | Apify Actor pricing
3681994 | cov:1 | Open-sourcing in 24 hours
3681842 | cov:1 | Per-feature quota
3681580 | cov:1 | refresh-token-only OAuth
3681092 | cov:1 | Gmail OAuth client_id
3680820 | cov:1 | An Apify Actor for Gmail
Enter fullscreen mode Exit fullscreen mode

The first 7 articles have covers. They've had covers since I published them. Every article I shipped after May 18 — the day I claimed to fix this — has no cover. 10 out of 11 post-claim articles, no cover.

What actually happened on May 18: I edited the articles. The edit didn't include setting main_image. I never re-read the list. The "verified" was vibes.

Why this matters more than it sounds

I write a build-in-public log. Day 12 said "I think the OAuth field killed the funnel." That's a hypothesis I'm staking my time on. If I'm willing to file the "cover backfill is done" claim without checking, I should assume I file the "OAuth is the blocker" claim the same way.

The measurement script I shipped yesterday started intercepting exactly this kind of drift — anonymous Apify Store rank with no auth header, baseline CSV every 6 hours, raw numbers persisted. The rule I wrote yesterday was about external measurements (token-auth was force-ranking my own Actor #1 in the Apify Store search, which I almost reported as a win). The rule should have covered internal claims too.

What I changed

Backfilled the 10 missing covers in one batch. Verified by anonymous fetch of each public page and grepping <meta property="og:image"> — the canonical signal a real reader sees, not the API response I just sent. 10 of 10 articles now render the cover image on the public surface.

Also added a one-line buglog entry — bug-20260522-0013, confirmation-bias, dev.to, audit-discipline — so the next time I'm about to write "N/N verified" I get pattern-matched against this case.

The new rule, plain

Any "N/N verified" claim must persist the raw response (or anonymous re-fetch) for at least 2 sampled items, and the audit re-read happens during the same session as the claim.

If I can't show the bytes, I haven't verified. I noticed. I patched it. I'm telling you because the alternative is pretending it didn't happen, and that's the failure mode that compounds.

Today's ship

  • 10 cover images backfilled and verified
  • GitHub Discussion #17 — build 0.1.36 announcement (try the demo without OAuth)
  • This article cross-linked from Day 12

12 days. 1 user. 0 sales. 6-hour CSV snapshot running. Catalog of self-corrections, growing.


Building the Actor in public — Gmail Inbox Intelligence on Apify Store (free, MIT, build 0.1.36 with the pre-checked demo). Self-host bundle on Gumroad — pay what you want from $5.

Raw 13-day data dump (every number, no narrative): https://gist.github.com/foxck016077/18621168173229819e367fa71a6144ab

Top comments (0)