The problem

I wanted small, single-purpose agents that return something you can check, not a chat answer. Examples of what they produce: NEAR wallet and contract reports, curve-fit and stats reports, site health grades, CSV dashboards, and BibTeX cleanup.

Design

One Python worker. It polls the market API for jobs instead of hosting a separate service per agent.

Plugin backend. Each agent is a plugin that does one job.

Deterministic outputs. The agents run plain code on public data, with no LLM in the loop, so the same input gives the same output and results are checkable.

Pricing

Jobs cost 0.10-0.50 USDC each, paid through market escrow.

Catalog

The catalog page shows a sample output for each agent: https://narwhalthepong.github.io/near-agents/

What would you hire an agent for?

I'll build what people ask for. Tell me in the comments which single-job agent you'd actually use.

Originally published on dev.to: https://dev.to/pau_drudis_6182de07fdc9f0/how-i-built-54-pay-per-job-agents-with-one-python-worker-and-zero-paid-infrastructure-1ml0

Check Gumroad's pricing page before relying on these numbers, since fees change.

What you keep

Two things stand out:

• Under about $5, the $0.50 dominates. A $1 product loses 60% to fees on a direct sale. That's why PWYW products with a $0 minimum or $1 tips barely move the needle.
• Discover takes a big cut, but it's still extra reach. Discover buyers are customers you wouldn't have found yourself. It's acquisition cost, not lost revenue.

Payment processing is on top of this in some cases, and payout methods can carry their own small fees. Look at a real payout once to see your true net.

Pricing around the fee

• Bundle low-priced items. Three $5 products sold separately cost $3.00 in fees. One $15 bundle costs $2.00.
• Use pay-what-you-want with a sensible minimum. A $9 minimum loses 15.6% to fees, and many buyers pay above it.
• Send your own traffic directly. Links from your blog, newsletter or social profiles are charged as direct sales at 10% + $0.50, not 30%.
• Price for the take-home amount. If you want $20 per sale, price at $22.78 or more: (target + 0.50) / 0.90.

Formula

direct_net   = price * 0.90 - 0.50
discover_net = price * 0.70
price_for_target_direct = (target + 0.50) / 0.90

Tools

• Creator Payout Calculator Pro runs these numbers in your browser for any price, so you can see direct and Discover payouts before you set a price.
• Gumroad Seller Finance Tracker imports your sales CSV and applies the fees to every row automatically.

More guides: Gumroad developer guides. Not affiliated with Gumroad.

const res = await fetch("https://api.gumroad.com/v2/licenses/verify", {
  method: "POST",
  body: new URLSearchParams({ product_id, license_key }),
}).then((r) => r.json());

if (res.success) unlock(); // looks fine...

The problem: success only tells you the key exists. After a buyer is refunded, files a chargeback, or cancels a subscription, /v2/licenses/verify still returns success: true. The status lives in the purchase object, so a check on success alone lets refunded buyers keep using your app.

The fix

Check the purchase flags too:

function evaluate(res) {
  if (!res?.success) return { valid: false, reason: res?.message ?? "invalid license" };
  const p = res.purchase ?? {};
  if (p.refunded) return { valid: false, reason: "purchase refunded" };
  if (p.chargebacked) return { valid: false, reason: "purchase chargebacked" };
  if (p.disputed && !p.dispute_won) return { valid: false, reason: "purchase disputed" };
  if (p.subscription_ended_at) return { valid: false, reason: "subscription ended" };
  if (p.subscription_failed_at) return { valid: false, reason: "subscription payment failed" };
  return { valid: true, reason: "ok" };
}

Python:

def evaluate(res):
    if not res or not res.get("success"):
        return {"valid": False, "reason": (res or {}).get("message", "invalid license")}
    p = res.get("purchase") or {}
    for flag in ("refunded", "chargebacked"):
        if p.get(flag):
            return {"valid": False, "reason": f"purchase {flag}"}
    if p.get("disputed") and not p.get("dispute_won"):
        return {"valid": False, "reason": "purchase disputed"}
    if p.get("subscription_ended_at") or p.get("subscription_failed_at"):
        return {"valid": False, "reason": "subscription inactive"}
    return {"valid": True, "reason": "ok"}

Two more tips

1. Send increment_uses_count=false on re-checks. By default every verify call bumps the key's uses count, so if you count activations, routine re-checks will burn through them. Only increment on the first activation.
2. Re-check now and then, not just once. Refunds happen after activation. A re-check every few days catches them. If you do this, cache the last good result so your app doesn't break offline.

Free code

I put both versions (zero dependencies, with tests) in a small MIT repo: https://github.com/NarwhalThePong/gumroad-license-check

If you want the production version, with a signed offline cache and grace period, activation limits, and a small proxy server so your product ID and logic stay off the client, I sell it as the Gumroad License Kit.

Have you hit other Gumroad API gotchas? Tell me in the comments.