DEV Community

Cover image for Day 12 build-in-public: 11 days, 1 user. I think the OAuth field killed the funnel.
foxck016077
foxck016077

Posted on

Day 12 build-in-public: 11 days, 1 user. I think the OAuth field killed the funnel.

#buildinpublic #apify #indiehackers #sideprojects

I open-sourced a Gmail inbox triage Actor on Apify Store on 2026-05-10. Twelve days later, the platform stats look like this:

"stats": {
    "totalUsers": 1,         // me, on the day I shipped
    "totalUsers7Days": 0,
    "totalUsers30Days": 0,
    "totalRuns": 6,          // 5/6 are my own test runs
    "bookmarkCount": 0,
    "actorReviewCount": 0
}
Enter fullscreen mode Exit fullscreen mode

For context, here's what I tried in those 12 days:

  • 15 dev.to articles (this is #16)
  • 2 awesome-list PRs merged
  • Apify Store description rewritten 4 times
  • Buyer-voice grounding from two Reddit threads (r/sales 1tdngew, r/smallbusiness 1td0827, 109 comments total)
  • 5 cross-linked GitHub gists ($19 / $99 sample reports)
  • A Gumroad $19 self-host bundle + $99 done-for-you tier

Zero sales. Zero organic Apify Store installs.

This is the part where most build-in-public posts pivot. I don't have a pivot to announce. I have one specific hypothesis I tested today, and the result is too early to call.

The hypothesis: the "Try for free" button doesn't actually try anything

The Actor takes a Gmail OAuth refresh_token + client_id + client_secret as input. Setting these up takes about 10 minutes (Google Cloud Console → create project → enable Gmail API → create OAuth client → walk through consent flow → grab refresh_token from the playground).

If I'm a curious dev landing on the Apify Store listing, I see a "Try for free" button. I click it. The input form pops up. The first required field is a nested JSON object asking for three OAuth values I don't have.

I close the tab.

I think that's been happening for 12 days.

What I changed (today, ~30 minutes of code)

The Actor already had a dry_run flag implemented — if dry_run=true, it skips OAuth and returns a synthetic 5-thread sample. The flag was sitting in the input schema, but two things were wrong:

  1. Position: dry_run was the 14th of 14 properties in the schema, way below the OAuth block. A first-time visitor never scrolled to it.
  2. required array: I had ["feature", "oauth_token"] listed as required. Apify's form validator refused to submit even if dry_run was checked.

Two-line diff:

- "required": ["feature", "oauth_token"]
+ "required": ["feature"]
Enter fullscreen mode Exit fullscreen mode 
- "dry_run": { "title": "Dry Run", ... }
+ "dry_run": {
+   "title": "Try demo (no OAuth needed)",
+   "description": "Check this on your first run. Returns a synthetic 5-thread output sample so you can see exactly what the Actor produces before setting up Gmail OAuth.",
+   ...
+ }
Enter fullscreen mode Exit fullscreen mode

Then I reordered the schema properties so dry_run sits right under feature, immediately visible.

apify push rebuilt the image as 0.1.34, took about 90 seconds.

I triggered a dry_run=true test run via API to confirm the fix works:

status: SUCCEEDED
exitCode: 0
runtime: 7.1s
dataset items: 2
compute units: 0.001
Enter fullscreen mode Exit fullscreen mode

Zero OAuth. Real-looking output. The visitor sees actual JSON within seconds of clicking "Run".

What I'm watching

totalUsers7Days over the next 48 hours. Current baseline: 0.

If the friction theory is right, I should see at least 1 organic user (not me) within 24 hours of the Apify Store search index re-crawling the listing.

If the friction theory is wrong, the deadlock is upstream: the listing isn't ranking in any search, so reducing input friction doesn't matter because nobody arrives to see the input form.

Either result is information. Public test, public log.

Side detail (one I burned)

I also tried to set the Actor to PAY_PER_EVENT pricing ($0.05 per stalled thread analyzed) to test whether paid actors get a different ranking weight on the Store. Apify enforces a 1-month cooldown on pricing changes; I burned it on a probe PUT before reading the docs carefully. Next pricing attempt: 2026-06-21.

Receipts

If you've shipped a paid open-source tool and seen the same pattern (high listing views, zero "Run" completions), tell me what you changed. I'll log it in the next post and credit you.

— Foxck

EDIT, 30 minutes later — my measurement was lying.

Right after publishing this post, I ran the new monitor script and saw gmail+inbox rank=1/149. Big win, right?

Wrong. The script was using my Apify owner token. The Apify Store search API personalizes for the authenticated caller — it force-ranks the caller's own Actors at #1 regardless of real keyword relevance.

A real anonymous visitor running the same query gets a different top 3:

1. getdataforme/hubspot-url-parser-spider
2. fayoussef/thebluebook-scraper
3. harvestlab/contact-extractor

foxck/gmail-inbox-intel: NOT FOUND in 149 results
Enter fullscreen mode Exit fullscreen mode

So the friction-reduction work (build 0.1.34, 0.1.35, 0.1.36 + prefill: true on dry_run) is real and apify push-verified. But the discoverability problem is upstream of the input form — Apify Store search does not surface the Actor in the first place. Reducing input friction does not matter if the visitor never arrives.

Lesson logged in my repo's build memory: any third-party visibility/rank measurement must use an anonymous query (no Authorization header), and verify the items list matches between auth and non-auth before trusting the number.

The 48h totalUsers7Days watch is still on. If it stays 0, the Apify Store side is dead for organic and the path forward is non-Store traffic (GitHub Topics page-1 surfaces, direct links, outbound) — not more polish.

Build 0.1.36 changelog + announcement: https://github.com/foxck016077/apify-gmail-inbox-intel/discussions/17

dry_run checkbox now pre-checked on first run + renamed to "Try demo (no OAuth needed)" + moved above the OAuth block. First-time visitors get a 5-thread synthetic sample in 4 seconds without touching Google Cloud Console. If the hypothesis is right, totalUsers7Days should move off 0 within 48h. 6-hour CSV snapshot running.

Top comments (0)