I open-sourced a Gmail Inbox Intelligence Apify Actor under MIT a few days ago. The Actor solves a problem freelancers have — which client emails went stale before the client follows up first? — using gmail.readonly OAuth, an async router, and per-feature quota tracking. Six dev.to posts cover the design.
But the Actor has a problem: most freelancers don't want to run a Python project to track 10 clients. They want labels and templates that just work.
So this afternoon I shipped a $9 manual companion: Freelancer Gmail Client Tracking Pack — 30 Gmail labels, 12 filter rules, 5 follow-up email templates, and a 40-line Apps Script that auto-flags any proposal silent for 7+ days.
Same underlying solution as the Actor. Different shape. Different buyer.
This is the build log.
Why split a product into two shapes
The Actor and the PDF solve the same problem at two ends of the same buyer spectrum:
| Actor (free, MIT) | PDF ($9) | |
|---|---|---|
| Buyer | developer running > 50 client threads | freelancer running 5-30 threads |
| Setup | clone, OAuth, Python, deploy | 30 labels + 12 filters in Gmail UI |
| Customization | fork the code | edit the JSON in a template |
| Maintenance | self-host | none, runs inside Gmail |
The Actor is the right answer when manual labels stop scaling. The PDF is the right answer when you've never set up a Gmail label system in your life. Pretending one product covers both audiences was the original mistake — solving for "developers who run Python actors" and "freelancers who barely know what Gmail filters are" with the same listing means losing both.
The framework I followed
The 4-hour shape came from a Douyin video I'd been chewing on. The framework was:
- Find demand, don't invent it. Search for what indie sellers are already moving (not what 1M-follower creators are doing — what 3,000-follower accounts with 5,000 sales are doing). If a tiny seller can move that volume, the demand is real and the bar is low.
- Pull the product out of your own experience. Not "what do I want to build" but "what do people already ask me about." The intersection of that question and step 1 is your product.
- Use AI to compress the build. 3-4 hours, not 3-4 weeks. The framework: AI for the skeleton, your real cases and mistakes for the filling.
- List where the buyer searches. A great PDF on a platform the buyer never visits is worth zero. SEO-style content (the search query the buyer would actually type) is the distribution.
The Actor I had already built was steps 1-3 for the developer audience. The PDF is the same steps for the freelancer audience — the underlying labels and SLA logic are identical, just repackaged.
The build, step by step
Step 1 — Validate the demand (5 minutes)
Searched "Gmail freelance follow up" on Reddit and Indie Hackers. Hit a 2026 IH article titled "Still Using Gmail for CRM? There's a Better Way" that directly framed the pain: "Gmail is just an inbox with labels and stars — no pipeline, no contact record tied to invoices."
That's my buyer typing the pain into Google. Validated.
Also checked Gumroad: there's a "Email Templates For Freelancers" listing in the same space — meaning some seller before me already proved people pay for this category. The differentiation: I have the Gmail-label-system + Apps-Script + 5-template combination, none of the existing listings have all three.
Step 2 — Extract the content from my existing work (90 minutes)
The Actor repo already had:
- The 30-label naming system in
INPUT_SCHEMA.json(pipeline stages, source tags, priority flags) - The SLA breach logic in
reply_metrics.py(the 7-day and 14-day cutoffs) - The follow-up templates I'd used myself (the proposal-stalled-then-replied conversations I had in the past year)
- 6 dev.to posts covering the OAuth, quota, and pricing design
The PDF is 80% extraction. Rewriting it for a non-developer audience was the actual work — removing every "you OAuth into a refresh-token-only flow" and replacing with "go to Gmail Settings → Filters."
Step 3 — Generate the deliverables (60 minutes)
- 10-page customer-facing PDF (HTML + CSS → headless Chrome
Page.printToPDFfor one-pass typography) - 40-line Apps Script (extracted the time-based relabel logic from the Actor's
reply_metrics, rewrote as a Gmail trigger function) - 5 follow-up email templates (each with: subject, body, send conditions, "do NOT use" guard rails)
- Friday 10-min audit checklist (1 page, printable)
The Apps Script was the most interesting part. The Actor's SLA detection runs on a server. The Apps Script runs inside Gmail on a 6-hour trigger, applying the same Stalled-7d / Stalled-14d labels. Different runtime, identical effect.
Step 4 — Listing + distribution (45 minutes)
- Created the Gumroad listing via Brave's CDP automation (cover image, thumbnail, $9 price, full description, content upload, publish)
- Added a cross-link block to the Actor's README ("Don't want to self-host? Get the manual pack")
- Appended a one-line CTA to all 6 existing dev.to posts in the series
- Wrote this post
Total elapsed: about 3 hours of focused work, 1 hour of small fixes.
What this proved (and what it didn't)
Proved: A repackage of existing work for an adjacent audience is faster than a new build. The Actor → PDF shape is 90% content reuse, 10% audience translation. If you have an open-source project with documented design choices, the productized version is almost certainly hiding in plain sight.
Didn't prove (yet): Whether the PDF will actually sell. The funnel is live (Gumroad + 6 dev.to CTAs + Actor README + Twitter), but the first cash-in moment is still ahead. The framework says "list where buyers search" — and dev.to isn't where freelancers search for Gmail label systems. Indie Hackers, Reddit r/freelance, and direct Google SEO are the real distribution channels for this product, and those are tomorrow's work.
Will follow up with the actual conversion numbers either way.
Related
- Actor (free, MIT): https://github.com/foxck016077/apify-gmail-inbox-intel
- PDF ($9): https://foxck.gumroad.com/l/freelancer-gmail-tracking-pack
- Series index: https://dev.to/foxck016077/series/39719
If you're sitting on an open-source project and wondering whether it has a paid companion product hiding in it: the answer is usually yes, and the build is shorter than you think.
Top comments (0)