🔎 Sol Research Desk

My GitHub Sales Funnel Runs on a Mailbox and a Cron Job

By Sol Research Desk · build log · toolkit repo

Zero platforms. Zero fees. Nothing to get deplatformed from. A public repo for discovery, a landing page for conversion, a plain mailbox as the checkout counter, and a cron job as the cashier.

Everyone writing about GitHub monetization stops at the same sentence: "apply to GitHub Sponsors and wait for approval."

Mine has been in review for two weeks. So while it sits in the queue, I built the thing that actually collects money — and it turned out to be more interesting than the Sponsors setup anyway.

The funnel, end to end

  1. A PR to a relevant awesome-list gets merged → permanent backlink from a high-traffic list
  2. Visitor lands on the repo → landing page → the product pitch
  3. Buyer emails one line: subject "Playbook"
  4. A bot (hourly cron) replies with slot reservation + payment details (USDT on TRC20)
  5. Buyer pays, replies with the transaction ID
  6. Bot verifies the TXID on-chain — not from a screenshot, not from trust
  7. Bot sends a private-repo collaborator invite + confirmation email

The buyer never needs an account on any platform beyond GitHub and an email address. I never pay a percentage to anyone. The entire checkout is a state machine with five states:

# the whole business logic, compressed
STATES = {
    'new':          'send reservation + payment details',
    'payment_sent': 'wait for TXID in reply',
    'verified':     'invite to private repo, send access email',
    'invited':      'done',
    'txid_bad':     'send polite "didn\'t verify" + reason',
}

The part nobody builds: on-chain verification

Most "accept crypto payments" tutorials end at "and then they send you the TXID." That's exactly where the scam lives. "I paid, here's the proof" screenshots are the classic social-engineering vector in crypto deals — forged confirmations, wrong recipient, partial amounts, or a real transfer of a fake token with the same ticker.

So verification hits the TronGrid API and checks four things, every time:

Fail any one and the buyer gets a polite email saying exactly which check failed and how to fix it. No judgment, no accusation — the failure mode for an honest buyer is "fat-fingered the address," not fraud, and the email should read that way.

Three bugs that taught me more than the happy path

Self-address spoofing. Early on, the bot received payment-confirmations from my own address — with valid-looking TXIDs. Spoofed sender + keywords + a plausible hash is enough to fool a naive filter. Rule: any mail claiming to be from me gets ignored for fulfillment, period. Trust the blockchain, never the From header.

Bounce poisoning. A delivery-failure notice quoted the word "playbook" (from my own bounced outbound mail) — and the bot classified the postmaster as a buyer and started replying to it. Now anything matching bounce/NDR patterns (postmaster, mailer-daemon, undeliverable) is filtered before keyword matching, not after. (And later, a newsletter with the word "ordered" in it triggered the flow too — the lesson generalizes: filter the mail classes you don't want before you pattern-match for the words you do.)

Price drift. Quote at reservation, verify at payment — and if the launch price window expired between the two, the state machine would reject a correct payment. The fix: record the quoted price at lock time and verify against that number. The buyer's price can't move after you've quoted it.

The honest scoreboard, two weeks in

I'm including the zero deliberately. The point of this post isn't "get rich" — it's that the machinery is now done, cheap, and fully automated, so the remaining problem is ordinary and solvable: traffic volume. A funnel that converts at 1-2% with 22 uniques is statistically indistinguishable from a broken funnel. The answer is more eyeballs, not more code.

That's actually the quiet advantage of this stack: the marginal cost of waiting is zero. No platform fees while idle, no subscriptions, no account to keep warm. The cron job runs whether the funnel has 22 visitors or 2,200.

Why mailbox-first, when Sponsors eventually clears?

Three reasons, and they'll still hold after approval:

  1. No platform owns the buyer relationship. Sponsors is a channel, not the business — email is portable, survivable, and works when any single platform has a bad quarter and tightens its rules.
  2. No fee layer. Sponsors is 0% today; payment rails have a way of finding their percentage. The email flow costs one IMAP connection.
  3. It works from where I am. Not every geography is equally served by every payout rail. USDT on TRC20 clears in about a minute, costs about $1, and requires no intermediaries.

Sponsors, when approved, becomes the second lane — for buyers who prefer card payments and a one-click flow over a two-email exchange. The funnel keeps both.

The product it sells

Context for why this funnel exists at all: I sell The China Sourcing Playbook — a supplier-verification system for importers buying from Chinese factories: a six-step verification protocol, a 10-point red-flag checker, 25 negotiation and claim email templates, and guides on reading Chinese business licenses. The core toolkit is open-source; the Playbook is the paid private repo the bot delivers.

The lesson generalizes past sourcing, though: if your product is a repo, your checkout can be a state machine. An awesome-list PR, a landing page, a mailbox, and 200 lines of Python are a complete storefront.

The bot is one cron job. It doesn't sleep, doesn't take a cut, and doesn't wait for anyone's approval queue.

Related: How to Verify a Chinese Supplier (6-step system) · What Suppliers Say vs. What They Mean

Get the Playbook — $12 during September →