AMA — Gmail-as-CRM, stalled-thread triage, OAuth & KVS quota patterns

[foxck016077]

Open thread — bring your stalled-thread / Gmail-as-CRM questions.

I built this Actor because I kept losing client proposals to forgotten follow-ups. The 11 dev.to posts cover the implementation choices — refresh-token-only OAuth, per-feature quota in KVS, the async router, the dry-run mode. They don't cover the practice of running your inbox like a CRM, because that varies wildly by how you actually work.

So: ask me anything in this thread. Some examples of useful questions:

• "How would I model stalled_score if my SLA is 48h instead of 7d?"
• "I use Gmail labels for client status — can I read those without gmail.modify scope?"
• "What's the right way to handle threads where I haven't replied but a teammate has?"
• "How do I run this as a Friday cron on Apify Free tier without burning my $5 platform credit?"
• "Could the unread-digest feature be repurposed for newsletter triage?"
• "What's the failure mode when client_secret rotates mid-run?"

I'll answer here in the open, and useful patterns I discover I'll fold back into the Actor docs (with credit). If a question turns out to be a bigger gap, it might become the next dev.to post.

Why this thread instead of GitHub Issues: Issues are for bugs and feature requests. This is for how do I use it — discussion territory. Conversational, exploratory, no template required.

About me: Solo, building in public, posting the daily log on dev.to. Day 9 today: $0 revenue, 0 sales, 1 GitHub star, 14 posts, 1 PR proposed upstream to apify/apify-docs. If you find something useful here, the cheapest thing you can do is leave a star or a question — both are signal that this is worth keeping the public.

Series: ZERO-TEN cold-start build log on dev.to

Latest tutorial: How to set up refresh-token-only OAuth for a multi-tenant Apify Actor (Gmail, 10 minutes) — also proposed as an official Apify Academy doc: apify/apify-docs#2549

— Hope (foxck on Apify / @foxck016077 on dev.to)

---

2026-05-22 update: Build 0.1.38 ships reply_metrics.priority_band (HOT/WARM/COLD field on over-SLA threads). 13-day raw data dump: https://gist.github.com/foxck016077/18621168173229819e367fa71a6144ab. Latest dev.to post is Day 14 — 184 reader, 0 follower, 0 sales on the analytics shock. AMA still open.

[foxck016077]

Maintainer note: how I'm thinking about OAuth setup friction for non-devs

The single biggest dropoff I see on this Actor is the Google Cloud Console + OAuth client + consent screen step. The Actor's job is simple once the credentials are there: rank stalled threads by SLA breach age, emit a JSON dataset, done. But for a buyer who isn't already comfortable in Cloud Console, the OAuth setup is a 10-minute detour through unfamiliar UIs before they ever see what the Actor does for them.

My current mitigation is a dry_run: true input boolean. When set, the Actor skips the OAuth exchange and emits a synthetic dataset matching the real output schema. The first interaction becomes "click Run, see what the JSON looks like," and the OAuth detour is only required once the buyer has decided the output is worth it. It hasn't broken the dropoff entirely — I'm still seeing 1 unique user across the lifetime of the Actor — but it removed the worst version of the first-touch experience.

Open questions I'd genuinely like input on (whether you've shipped your own multi-tenant Google API Actor or you're a buyer who hit one of these walls):

1. Is there a cleaner setup path I'm missing? I covered the refresh-token-only pattern in this tutorial (also submitted as a PR to docs: add Python tutorial for refresh token OAuth in multi-tenant Apify Actors apify/apify-docs#2549): https://dev.to/foxck016077/how-to-set-up-refresh-token-only-oauth-for-a-multi-tenant-apify-actor-gmail-10-minutes-4o9o — but I'm aware "Desktop app OAuth client + paste 3 strings" still requires Google Cloud Console familiarity that a non-dev buyer might not have.

2. For buyers: if you've used an Apify Actor that asked for an OAuth refresh token, what made the difference between completing the setup and giving up? Was it the docs, the dry-run option, a video walkthrough, or something else entirely?

3. For builders: are you handling first-touch differently? Hosted callback URL, Apify-side OAuth proxy, magic-link onboarding, anything I haven't considered?

This thread is open. Replies don't need to be polished — even one sentence of "here's what I tried" helps me figure out which lever to pull next.

[foxck016077]

Update — v0.2 web wrapper scoping (2026-05-20)

Two days after opening this thread, the OAuth-friction dropoff is still the single loudest signal. Putting a hosted web wrapper in front of the Actor — Google one-click sign-in, no client_secrets.json, no INPUT.json — is the v0.2 direction I'm scoping.

I just landed a Roadmap section in the README (f089a22) with the v0.2 outline and a 2026-05-20 competitor scout.

What I found in the competitor scan (verified today):

• Mailbutler — $4 to $11 / month, freemium + 14-day trial. Outbound tracking + signatures, not stalled-thread.
• Boomerang for Gmail — freemium + Pro tier (their dedicated /pricing page is currently broken). Snooze + scheduled send.
• Streak / Mixmax / Instantly — $15 to $59 / month. Gmail CRM + mass outbound automation.
• Right-Inbox — domain DNS no longer resolves.

None of them visualize stalled threads ranked by silent age as a read-only inbox health view. They're all outbound-flavored. That gap is what v0.2 targets.

Three open questions I'd want builder + buyer input on before I cut code:

1. Pricing entry. Stage 1 free + email collect → Stage 2 $7 / month paid tier once there's a list. Or skip the free stage and ship paid from day one? My gut says free-first wins for a tool people need to feel comfortable wiring to gmail.readonly, but I could be over-weighting that.

2. Domain vibe. Considering coldthreads.app, inboxintel.so, or silentthreads.app. Direct / tool-flavored / abstract respectively. Or another suggestion entirely.

3. Landing line — outcome-first 1-sentence value prop. Candidates:

   • "See which client emails went cold this week."
   • "Your inbox knows which leads ghosted you. Show me."
   • "30 seconds to find the 5 client threads you forgot."

   Or write your own.

If you've actually run cold-thread triage out of Gmail before — for client work, sales pipeline, or your own follow-ups — what would have made you sign up vs bounce? Bonus points if your reasoning includes "I'd never trust a brand-new SaaS with my inbox unless…" because that constraint shapes the trust signals on the landing.

Will cross-post the full spec once the domain is locked.

[foxck016077]

Update — v0.2 preview UI shipped (still 2026-05-20)

Two hours after the scoping reply: the v0.2 preview UI is live in foxck016077/gmail-inbox-web.

What's in this commit:

• Next.js 16.2.6 + React 19.2 + Tailwind v4 + TypeScript
• Landing copy locked to candidate 1 from the previous reply: "See which client emails went cold this week."
• Stalled-thread table sorted by days_silent desc, SLA breach flag at 30 days
• /api/threads.csv route handler, UTF-8 BOM for Excel
• 20 sample threads in app/lib/mock.ts so the page is real before OAuth lands

What's not yet in:

• Google one-click sign-in (gmail.readonly only) — next commit
• Real Gmail API call replacing the mock — same commit as OAuth
• Custom domain (still on Vercel preview subdomain)

The reason the UI ships before OAuth: getting the visible flow real makes the spec arguments cheaper to settle. If you click into the preview repo and the table feels wrong (column order, sort, what SLA breach means), saying so now costs less than rewiring after auth is in.

Still curious about the same 3 questions from earlier this thread — pricing entry, domain vibe, landing copy. The current vote is: free + email collect Stage 1, coldthreads.app as working name (open to others), and the landing line above. None of those are locked.

Local dev: npm install && npm run dev. Vercel deploy: clone and import; no env vars required for the preview build.

[foxck016077]

Update — OAuth wiring shipped (commit 256d2c8)

30 minutes after the preview UI commit: NextAuth v5 + Google provider + the real Gmail API call are all in the repo.

• auth.ts — JWT strategy, gmail.readonly scope only, access_type:offline + prompt:consent for refresh, refresh-on-demand with a 60s clock skew. refresh_token lives on the JWT, never touches disk.
• app/lib/gmail.ts — 5-concurrent pool against threads.list + threads.get (metadata format only, fields scoped to Subject, From, To, internalDate). Counterparty resolved by walking message history for the first non-self From. days_silent from max internalDate. SLA breach at 30 days.
• app/lib/threads.ts — dispatcher returning { threads, source: "live" | "mock", error? }. When no session or refresh fails, falls back to sample data with a banner so the page never hard-crashes.
• app/page.tsx — 3-state status pill (Preview / Sample-but-signed-out-error / Live), error banner for refresh failures.
• Sign-in / sign-out via server actions in AuthControls.tsx.

What this leaves Fox-side:

1. Cloud Console — register OAuth client (Web app), enable Gmail API, add gmail.readonly to OAuth consent scopes. One-time.
2. Vercel project — paste AUTH_GOOGLE_ID, AUTH_GOOGLE_SECRET, AUTH_SECRET (openssl rand -base64 32).
3. Until OAuth consent is verified for the sensitive scope, the app stays in Testing mode (specific Gmail addresses must be on the Test users list). Verification is its own queue at Google; production sign-in for arbitrary users waits on that.

The unauth flow was smoke-tested locally: landing renders, "Continue with Google" shows, /api/auth/signin/google returns 400 without env vars (correct).

The whole pivot — spec → preview UI → OAuth wiring — landed in one session because the AMA gave me a sanity check on whether the gap is real. The competitor scan said the gap holds. The README and the spec are the same shape. Open thread still: pricing entry, domain, landing copy. Same 3 questions, OAuth changes none of them.

[foxck016077]

Update — Done-For-You $99 tier added + listings rewritten outcome-first (2026-05-20)

After 9 days of $0 sales I ran a 4-source demand audit (Reddit / YouTube / Upwork Jobs / Fiverr Gigs) and found zero "I want a stalled-thread tool" buyer voice — what's there is outbound automation (GMass-class), VA inbox-zero tutorials, and email-list deliverability. None of those are this tool's frame.

Two falsifiable changes from that finding:

1. All three listings rewritten outcome-first. Old hook was "self-host Apify Actor template — reply tracking, SLA breach detection, four features." New hook is "You're losing deals you didn't know were dying. Every Friday, open Gmail. See which client threads have gone silent past their SLA." Same product, different framing of who-it's-for.

2. Done-For-You triage tier added at $99. Buyer pays $99, sends an email after purchase, I run the scan on their Gmail (refresh-token OAuth, read-only, never stored), they get a 1-page Friday triage report within 7 days — top 10 cold threads, days silent, suggested re-engage angle. No setup on their side. This tests whether receiver-side pain exists but doesn't get vocalized the way I expected.

Listings:

• $99 DFY → email after purchase of either tier, subject "DFY Triage"
• $19 self-host → foxck.gumroad.com/l/freelancer-gmail-tracking-pack
• $0 PWYW template → apify.com/foxck/gmail-inbox-intel

Write-up of the demand-audit reasoning + competitor outcome-first patterns: Day 10 build log.

If anyone reading this has a stalled-thread problem in their own inbox and wants to test the DFY tier first — you'd be the first buyer and I'd discount it to $49 in exchange for honest feedback on the report format.

[foxck016077]

5/21 Update — shipped reengage_angle feature grounded in r/sales 49-comment thread

The previous v0.2 update floated three pricing/positioning questions. None resolved yet, but the buyer-voice work this morning reshaped the product itself.

TL;DR: r/sales 1tdngew (49 comments, "what is your actual process for re-engaging a prospect who went cold six months ago") had 12 commenters say variations of "lead with new context, not reminders". 0 commenters asked for a sorted stalled-thread list. Critical mismatch with what this actor was outputting.

Shipped today (build 0.1.26):

• New feature reengage_angle — for each cold/over-SLA thread, fetch Google News headlines about the counterparty company over the last 90 days. No API key required for the headlines layer.
• Optional LLM enrichment (same openai_api_key the existing summarizer uses) — drafts 3 short re-engage email options per cold thread, each grounded in a specific news item. Directly maps to the one commenter who explicitly asked for "AI to analyze context and give me the best approach".
• 4 new pytest tests, full suite passes (11/11)

Buyer voice grounding doc + raw thread JSON cache live at the repo root (look for BUYER_VOICE_SYNTHESIS_2026-05-21.md once I push it).

Open questions for anyone running cold-prospect re-engagement:

1. What signal source beyond Google News would help? LinkedIn role-change check is the obvious one but their anti-bot makes it hard from a non-credentialed actor. Anyone solved this cleanly?
2. Is the right LLM output 3 drafted emails (current), or a structured "angle suggestion" (news + why-it-matters + suggested-CTA) that the seller writes from?
3. SLA threshold default is 14 days. For 6-month-cold prospects (the OP's scenario), is a separate "dormant" threshold useful, or does one threshold work?

Run it on the Apify Store: https://apify.com/foxck/gmail-inbox-intel — pick reengage_angle from the feature dropdown.

[foxck016077]

5/22 Update — Day 16: 35 surfaces saturated, 1 real engagement signal landed

After 16 days of cold-start, the funnel reads:

• dev.to: 245 readers/week (up from 184), 0 followers, 1 reaction, 21 articles
• GitHub: 6 page views / 14 days, 1 organic star (@kuerdy), 0 external Discussion comments
• Apify Store: 8 Actor runs lifetime, all by me, 0 external installs, rank ~1125/1126 in BUSINESS
• Gumroad: 10 products listed, 0 lifetime sales across all 10

What I shipped today (all listing/copy iteration, no new article — committed publicly to a 24h moratorium on Day 16):

1. All 10 Gumroad listings refreshed with the same "Day 16 build-in-public log" trust block + audit-honesty hook (Day 13 — caught my own claim of "7/7 covers backfilled" being false, fixed to "actually 1/12"). The 4 n8n templates now form a reciprocal cluster mesh (5-pack ↔ Lead Responder ↔ Competitor Monitor ↔ Content Pipeline).
2. All 21 dev.to articles got a "More from the shop" footer linking Claude Code Mastery $49, the n8n bundle $29, and AI Lead Auto-Responder $39 + a back-link to the Day 16 checkpoint article. Every entry point now sees the full catalog.
3. dev.to author profile filled out (was 4/5 fields empty across every comment byline — leak fixed: bio + available_for + currently_hacking_on + location + work).
4. GitHub repo description refreshed + topics swap: added build-in-public, claude-code, cold-start, indie-hacker; removed 4 redundant client-* topics.
5. Caught a self-overselling claim: the "30-second start, no signup" copy was sending anon readers to apify.com which requires a free Apify account. Fixed on README, Apify Store, Day 16, Day 9, and the $19 Self-Host listing. The honest path: anon-readable Friday Triage gist shows the output; Apify Actor requires signup to run the execution.

One concrete engagement signal landed today — @tokidigital (Japan-based Amazon seller building Japan Brand Finder, also 0 customers) replied to my Day 9 PWYW analysis on his Japan-sourcing article with a substantive numbers-trade request. We're now exchanging weekly receipts: his cache-miss enrichment economics ↔ my listing-rewrite-vs-conversion data. His framing — "engage before you're engaged with, consistently; the graph slowly thickens" — is the unglamorous reciprocal-first model I'm now applying.

If you're cold-starting a tiny product and have a counter-question on any of the above — pricing, OAuth friction, dev.to algo behavior, the Apify signup wall — drop it in this thread. The Day 13 "audit-myself-honestly" habit means I'd rather have a real disagreement than a polite agree-with-everything reply.

Series: 21 build-log posts on dev.to. Latest: Day 16 — +51 reader spike in 85 min, 0 sales, here's what actually moved.

[foxck016077]

5/23 Update — Day 17: 25 surfaces saturated, 2nd real reader signal landed (dimagious), Brave-bypass dev.to PUT API found

After 17 days of cold-start the funnel reads:

• dev.to: 247 readers/week, 0 followers, 22 articles published, 2 real reader replies in week 2 (tokidigital on Day 13 PWYW thread + dimagious on his own "first 30 seconds" thread — both public, both substantive, dimagious 27h reciprocal reply after my outbound comment)
• GitHub: 1 organic star (@kuerdy), 0 external Discussion comments still
• Apify Store: build 0.1.44 deployed, 8 Actor runs (0 external users), Discover rank dead
• Gumroad: 0 sales, 10 listings — 3 main funnel listings (PWYW $0+ / Self-Host $19+ / pbot $0+) all PUT today carrying Day 17 + 2 real reader thread links

Day 17 push specifics:

1. Cut the $9 PDF, 25-min pivoted to pbot (one-click personal knowledge bot for LINE / Telegram / Zalo) — daily-use workflow product hypothesis (PDFs don't form daily-use dependencies)
2. 20/20 dev.to article footers retrofitted with Day 17 + tokidigital + dimagious cross-link block via PUT /api/articles/:id — api-key plus Mozilla UA bypassed Cloudflare "403 Forbidden Bots" that was blocking python-urllib UA
3. 3 Gumroad PUT + README push + 20 dev.to article PUT + Apify rebuild = 25 surface mesh saturated with Day 17 + 2 real reader links

Brave-bypass discovery: dev.to public API api-key was throwing 403 Forbidden Bots on PUT until Mozilla/Chrome UA header was added. POST /api/comments still returns 404 (not a public endpoint — comment ship still requires logged-in browser session). Body edits + tag PUTs work via UA workaround.

Still no purchase. Funnel mechanically saturated; what's missing is reader → buyer conversion friction — probably the OAuth field (Day 12 post-mortem hypothesis still untested). Next experiment lever: $0 PWYW → $29 paid anchor flip — pending owner tap.

Latest post-mortem: Day 17 — cut the $9 PDF, 25-min pivot spike out a new direction.

[foxck016077]

Day 18 update (2026-05-24)

Published: SQLite FTS5 won't tokenize Chinese — here's the 7-line bigram fix that did

The pbot spike uses SQLite FTS5 for retrieval. unicode61 tokenizer returns 0 hits for CJK queries because it treats entire character runs as single tokens. A 7-line bigram preprocessor splits CJK runs into overlapping 2-char pairs before insert and query. 15,119 chunks / 0-3 ms query latency.

Cumulative stats: 23 dev.to articles / 258 views / 1 reaction / 0 sales / pbot v1 dev preview shipped (93 MB .dmg + daemon auto-start + setup-confirm endpoint)

Next: Day 19 — Docker fallback packaging (65.9 MB image, already built).