Forem: foxck016077

Apify Actor pricing patterns: Free tier + Pro + Pay-per-result — designing for indie buyers

foxck016077 — Sun, 17 May 2026 01:30:52 +0000

Most pricing conversations start with "how much per month." For a small Actor product, that's the wrong starting question. The better one: what kind of risk is the buyer trading for money?

Indie buyers care about three risks:

Onboarding risk — will I lose an afternoon and still not get it working?
Cost risk — will the monthly bill stay predictable, or surprise me?
Switching risk — do I have to rebuild a workflow I already trust?

So my default shape for an Actor is Free tier + Pro + Pay-per-result. Not because three tiers look professional — because each one absorbs one of those risks.

Free tier is trust validation, not generosity

Free is not "I'll give you a taste." Free is "I'll let you prove to yourself this thing works on your data, end-to-end, before you give me money."

If your free tier doesn't support a real decision — if it only shows demo data, or caps so aggressively you can't reach the moment of insight — your upgrade rate will be terrible. People will assume the paid version is the same friction, with a price tag.

Concrete signal: a buyer should be able to run the actual core path on a small slice of their own real workload, and recognize "yes, this is the value."

Pro is predictability, not "more buttons"

The least useful Pro page in the world is a feature-comparison table where the Pro column has more checkmarks. Small-team buyers don't pay for checkmarks. They pay to remove uncertainty.

The sustainable Pro pitch is stability:

Predictable monthly quota that won't get squeezed by a noisy neighbor
Critical features (the ones their workflow now depends on) won't degrade under peak load
Less friction when a teammate needs the same workflow

That's what "Pro" actually means to a 3-person agency or a solo freelancer running a real practice on top of your tool.

Pay-per-result is for the elastic edge

Subscription-only pricing punishes both ends of the curve. Heavy occasional users feel cheated by the cap. Light steady users feel they're prepaying for capacity they never use.

A pay-per-result layer is the release valve: a buyer can sit on Pro for the predictable baseline, and spike on top with metered usage during a busy month. Both shapes get to convert.

But this only works if what counts as one "result" is unambiguous, and your system can identify it reliably.

Pricing is a product of architecture

Here's the part I underestimated on v0: pricing and architecture cannot be designed independently.

Routing layer needs to know which feature was invoked
Quota layer needs tenant + month + feature granularity
Result layer has to emit countable, attributable events
Observability layer has to support the inevitable billing dispute

If any of those four layers is broken or ambiguous, the billing model collapses the first time someone disputes a charge. So design the meter first, then attach numbers.

(I wrote up the quota layer specifically in an earlier post in this series.)

What "good pricing" actually means

Good pricing isn't extracting one more dollar per transaction. Good pricing is losing one fewer buyer at each step of trust:

Free tier — they don't bounce on the install
Pro — they don't churn at month two when "cool" wears off and only "useful" remains
Pay-per-result — they don't switch tools the first time their usage spikes

That's the indie-buyer growth path, and it's the one a 3-tier shape is designed for. The trick isn't the three boxes — it's making sure each box matches the risk that buyer is actually carrying.

If you're productizing your own content / operations workflow and need a starting template that already separates the "metering" layer from the "delivery" layer, the AI Content Pipeline bundle is built on the same per-feature counting pattern.

GitHub repo: https://github.com/foxck016077/apify-gmail-inbox-intel
Series index: https://dev.to/foxck016077/series/39719

Open-sourcing an MIT Apify Actor in 24 hours — a build log

foxck016077 — Sat, 16 May 2026 07:59:09 +0000

This is a 24-hour open-source log, not a myth. The goal was never "one-shot perfection." The goal was a maintainable v1 — something someone else could read, run, and extend.

Step 0: cut scope

I kept four things, and four only:

A working main path
Clear feature boundaries
Basic async tests
Readable docs

Anything that would slow delivery without affecting first-version usability — out. Not deprioritized, not "later." Out.

Hours 0–6: execution path first

Make input → output traceable. Don't reach for clean abstractions yet. Early abstraction usually just hides bugs under nicer-looking surfaces. I'd rather have ugly, traceable code than tidy code I can't reason about.

Hours 6–10: OAuth timing

This was the real puzzle. Which errors should fail fast? Which should prompt the user toward a recovery action? Which states should I leave intact for a retry to pick up?

Working through this told me something I wasn't expecting: authorization is not a side feature. It's the usability foundation. If the auth flow is sloppy, nothing downstream feels reliable.

Hours 10–14: quota lives in the main flow

Quota does not get bolted on at the end. If you add metering late, it almost always drags pricing logic and error semantics into the rewrite with it.

So I put a small KeyValueStore-backed per-feature counter directly in the request path. No DB, no cron. (Wrote it up separately as part of this same series.)

Hours 14–18: the unglamorous cleanup

Async test coverage on the happy path and the obvious failure modes. Exception paths. Naming boundaries that won't bite a future contributor. None of this is exciting. All of it prevents the first wave of post-launch issues from being existential.

Hours 18–21: README + MIT license

MIT matters for indie builders in a very practical way: it removes the "can I actually use this?" friction. Collaboration is more valuable than control, especially when you have zero stars and need the door wide open.

Last 3 hours: stranger's-eye review

Read the repo as if I'd never seen it. Run the project from scratch following only the README. Check that nothing private leaked into commits.

This is the easiest step to skip and the most reliable way to catch your own blind spots.

What I'd say to a past me

Speed isn't typing fast. Speed is deciding fast what not to build.
Open-source quality isn't zero bugs. It's "visible, reproducible, fixable."
The auth layer is the foundation, not a feature. Get it right early or pay forever.

If you want to turn this kind of 24h sprint into a repeatable workflow, I bundled the scope-cutting, commit-cadence, and acceptance templates I used here: Claude Code Workflow Pack (pay-what-you-want).

GitHub repo: https://github.com/foxck016077/apify-gmail-inbox-intel
Series index: https://dev.to/foxck016077/series/39719

Per-feature quota in Apify KeyValueStore — no DB, no cron, no drift

foxck016077 — Sat, 16 May 2026 07:21:29 +0000

The reflex when you hear "quota" is to reach for a database plus a cron job. For a small, self-maintained Actor I care more about complexity: the heavier the system, the harder it is to keep stable for months.

For this project I went with KeyValueStore plus a month-key. The goals were clear:

Meter per feature, not just total invocations
Reset naturally each month — no scheduled job
Keep the logic in one place so it doesn't drift

The trick is in the key layout. Conceptually:

quota:{tenant}:{feature}:2026-05

When a new month starts, you write to a new key. You don't wipe the old one. "Reset" becomes a naming switch, not a data migration. No month-end task can fail, and you don't have to think about timezone edges either.

Per-feature matters because feature cost varies wildly. If you only meter the total, heavy features crowd out light ones, and everyone ends up feeling like the limit is unfair.

The discipline in quota.py is small but strict:

Check the limit before doing the work
Only record after the operation actually succeeds
Keep the key format fixed — no variants
On failure, do not write a guess

"No drift" isn't an algorithmic property. It's a write-semantics property. The moment your counter writes are scattered across modules — each doing it slightly differently — you've already lost.

This design is not universal. It fits products with low-to-medium complexity, multi-tenant but with bounded concurrency. If you later outgrow it, swapping in a real metering pipeline is a clean migration, because the surface is small.

My one piece of advice: get the quota schema right in the first version. Adding it later almost always drags pricing, routing, and error semantics into the rewrite with it.

If you're building SMB automation services, the n8n SMB Automation Pack ($29) pairs nicely with this pattern — quota, retries, and notifications all live in one operable flow.

GitHub repo: https://github.com/foxck016077/apify-gmail-inbox-intel
Gumroad: https://foxck.gumroad.com

Previous notes in this series:

Why I picked refresh-token-only OAuth for a multi-tenant Apify Actor

foxck016077 — Sat, 16 May 2026 06:02:29 +0000

Building a Gmail analytics Actor, the first real decision was not the report format. It was the authorization model. In a multi-tenant context, OAuth stops being purely a security question and becomes a product friction question.

I ended up with refresh-token-only instead of running a full 3-legged flow on every invocation. The reasoning is mundane and practical.

The operational reality of an Actor

Actors mostly run from schedules or non-interactive pipelines. If every run requires a fresh human consent, the automation degenerates into manual labor. That single decision quietly eats the entire value of the tool.

You can model this as a unit-economics question: every extra interactive consent step is a tax on every future run. With a refresh-token model, the human pays the consent cost once, then the workflow runs free.

Why not "platform-managed" delegated access

A natural shortcut is "let the platform manage it" — store user credentials centrally, never bother the user again. I avoided this on purpose.

The category of data here (inbox content) is sensitive by default. I do not want the product to be designed around "trust me first." I prefer a verifiable model: explicit user authorization, controllable scope, revocable token, recoverable failure path. Anything that requires the user to extend trust beyond what they can audit is a future incident waiting to happen.

Refresh-token-only as an observability win

There is a less-obvious reason refresh-token-only works well in multi-tenant. Failure modes converge.

Common errors collapse into a small, named set:

token expired
scope insufficient
API rate-limited

Instead of a tangle of callback/session/browser-state issues. As the maintainer, this kind of observability matters more to me than a flow that "looks more standard." Production debugging is dominated by the worst few failure modes; making those modes obvious is worth a lot.

Privacy posture

Take the minimum usable data, not the maximum available data. Functionality can grow slowly. Authorization boundaries should be clean from day one. Once you have taken too much, pulling back is almost always painful — and visible to the customer in a way that reads as a downgrade rather than a fix.

This is a small mindset thing that compounds. Every new feature decision starts from "what is the smallest scope that lets this work?" instead of "what scope unlocks the most options?"

Three questions before you copy this

If you are working on multi-tenant automation, the three useful questions are:

Is your flow interactive, or batch?
Are you optimizing for first-run experience, or long-run stability?
Are you building trust through marketing language, or through revocability and audit boundaries?

The answers reorder a lot of design choices. For my Actor — scheduled, multi-tenant, sensitive scope — refresh-token-only was not the flashiest choice. It was the one that matched how Actors actually run: schedulable, maintainable, explainable.

Closing

Refresh-token-only is not a clever pattern. It is a boring one. Boring is what you want from authorization code, because the interesting code is supposed to live downstream of the auth boundary, not inside it.

Repo: https://github.com/foxck016077/apify-gmail-inbox-intel (MIT)
If you are designing automations where authorization, retry, and alerting all need to live in one operable loop, the related toolkit page is: https://foxck.gumroad.com — AI Automation Workflow Pack ($29) is the closest match on theme.

Gmail OAuth client_id is not a secret â design notes for self-host Actors

foxck016077 — Sat, 16 May 2026 03:20:01 +0000

This question keeps coming up:

"My Gmail OAuth client_id got leaked. Is the system compromised?"

Short answer: client_id was never a secret. What you actually need to protect is the token, the client_secret (if your flow uses one), and the overall authorization exchange boundary.

This matters more in a self-host Actor scenario, because you are not shipping a single deployment â€” every user runs it their own way.

Public identifier, not sensitive credential

The OAuth client_id is closer to an application identifier than a password. It needs to be visible to the OAuth server and the front-end flow. In many scenarios it appears in places that are reasonable to see.

Treating client_id like a password and "hiding" it is usually a misunderstanding:

You cannot hide it (front-end, request URLs, logs all expose it)
Hiding it does not raise overall security
Worse, it can distract you from the real attack surface

The question worth asking is: if an attacker knows your client_id, what can they still do? If the answer is "nothing â€” they cannot complete an authorization exchange or obtain a valid token", your design is pointing in the right direction.

Where the security budget actually goes

For a self-host Actor, security is about flow integrity, not a single magical value. I focus on four layers:

redirect URI allowlist â€” only registered and verifiable callbacks
state / anti-CSRF â€” every authorization round-trip is bound to the originating session
token storage and rotation â€” least privilege, shortest exposure, revocable
tenant isolation â€” every token is namespaced to a tenant and never crosses boundaries

If these four layers are solid, client_id visibility is not a primary risk.

Common mistake: budget in the wrong place

I have seen projects spend real effort on "obfuscating client_id" while ignoring problems that actually cause incidents:

weak callback endpoint validation
tokens accidentally landing in logs with broad ACLs
error handlers leaking internal state to the caller
inconsistent multi-tenant key naming that lets one tenant trip into another's data

Those are the things that bite.

Security is not about mystique. It is about staying recoverable in the worst case.

What this means for multi-tenant Actor design

Once you accept "client_id is visible by design", the architecture gets cleaner. Attention naturally shifts to:

scope minimization â€” request only the permissions you truly need (in my Actor, gmail.readonly and nothing else)
explicit token lifecycle â€” when it renews, when it expires, when it can be revoked
auditable execution path â€” which tenant triggered which run when

These decisions directly affect product trust and how much firefighting future-you will be doing.

Self-host does not exempt you from threat modeling

A tempting shortcut: "It's self-host, so the risk lives with the user."

That is half right. Yes, deployment responsibility moves to the operator. But as the author you still owe secure defaults:

safe defaults rather than risky defaults
explicit documentation rather than verbal hints
observable errors rather than silent failures

Otherwise you are not reducing risk, you are just shifting it.

Documentation pattern

For OAuth-touching repos, I now write three things first:

Which values are public, which must stay private
The lifecycle and revocation path for every token
What a user can actually do when an authorization error happens

Two effects:

new users do not get blocked on a panic about the wrong thing
experienced reviewers can audit your security logic quickly

The clearer you are, the easier it is for the community to trust your project.

Open-source carries extra weight

In open source, a misleading security narrative is more dangerous than in a private product, because it gets copied.

If you frame client_id as "top secret", others will copy that posture and ship the same broken model with real problems intact.

I prefer to spell it out in the README:

client_id is expected to be visible
the real sensitive surface is token handling and flow protection
multi-tenant isolation is enforced through data structure and routing logic

That way, even a fork carries a less-wrong threat model forward.

Closing: stop asking "can I hide it"

The question I keep on a sticky note for OAuth design is:

"If this value gets seen, is the system still safe?"

If a single exposed value collapses the system, the problem is not secret management â€” it is brittle architecture.

For Gmail OAuth in a self-host Actor, client_id is not the protagonist. The real protagonist is a verifiable, revocable, isolated authorization system.

Repo: https://github.com/foxck016077/apify-gmail-inbox-intel (MIT)
If you work on long-running agents and workflow systems, the related theme â€” namespacing state, permission, and context boundaries to keep an expanding system controllable â€” is something I think about a lot. Toolkit page: https://foxck.gumroad.com

📚 Part of the Apify Gmail Inbox Actor — design notes series.

An Apify Actor for Gmail inbox analytics â refresh-token-only OAuth, async router, per-feature quota

foxck016077 — Sat, 16 May 2026 01:31:10 +0000

I just open-sourced an Apify Actor for Gmail inbox workflow analytics: apify-gmail-inbox-intel. It is not a scraper, not a bulk sender â€” it is an inbox analytics tool on gmail.readonly scope. This post is a design tour, not a tutorial.

If you have ever asked "which client thread did I forget to reply to?" or "what is my average reply turnaround?", this is the kind of workflow it covers.

Why an Apify Actor

I needed three things at once: serverless runtime, pay-per-result billing, and a real input schema. Apify gives me all of them without writing a backend. I get a hosted endpoint, dataset storage, a key-value store for state, and a developer audience that is already paying for actors.

The actor exposes four features through a single entrypoint:

thread_search â€” query Gmail threads by q, paginate, return metadata + message counts
reply_metrics â€” for each thread, compute reply-from-me, reply-from-others, last-reply age, SLA breach flag
summarizer â€” optional OpenAI LLM thread summary (BYO API key)
unread_digest â€” list unread threads in the last N hours, grouped by label

Design decision 1: refresh-token-only OAuth

The hardest call early on was OAuth. Two paths:

3-legged OAuth on the Actor side â€” Actor hosts callback URL, exchanges code, stores tokens.
Refresh-token-only â€” user does the OAuth dance once on their own, hands me {refresh_token, client_id, client_secret} as Actor input.

I picked option 2. Reasons:

Apify Actors do not have a stable HTTPS callback URL per user. Each run is a job, not a server.
"We never store your Gmail tokens" is a far easier privacy story to defend.
I do not want to be the holder-of-secrets for someone else's mailbox.

In the Actor, the flow is:

# src/gmail_client.py â€” sketch
async def get_access_token(oauth_token: dict) -> str:
    resp = await httpx_client.post(
        "https://oauth2.googleapis.com/token",
        data={
            "grant_type": "refresh_token",
            "refresh_token": oauth_token["refresh_token"],
            "client_id": oauth_token["client_id"],
            "client_secret": oauth_token["client_secret"],
        },
    )
    return resp.json()["access_token"]

Access token lives in memory only. Job end â†’ process tears down â†’ token gone. Best effort, but at least nothing persists in Apify storage with my code path.

Design decision 2: one async router, not four actors

Tempting to split into four actors. I did not, for two reasons:

Marketing surface area. One actor with four feature enum values gets one Store page, one rating, one review pile. Four actors split everything four ways.
Shared OAuth + shared quota. The token exchange, error handling, mask helpers, KVS quota â€” all reusable.

src/main.py is just a router:

FEATURES = {
    "thread_search": thread_search.run,
    "reply_metrics": reply_metrics.run,
    "summarizer": summarizer.run,
    "unread_digest": digest.run,
}

async def main():
    actor_input = await Actor.get_input() or {}
    feature = actor_input.get("feature")
    if feature not in FEATURES:
        raise ValueError(f"Unknown feature: {feature}")
    await FEATURES[feature](actor_input)

Each feature module owns its own INPUT_SCHEMA.json semantics through the same shared file â€” the feature enum drives validation downstream in each handler.

Design decision 3: quota lives in Apify KVS

Free tier is 100 threads / month. That counter has to survive across runs. Apify KeyValueStore is the obvious home â€” no extra DB, persistent, scoped to the Actor.

# src/quota.py â€” sketch
async def check_and_increment(user_id: str, feature: str, n: int):
    kvs = await Actor.open_key_value_store()
    key = f"quota/{user_id}/{month_key()}/{feature}"
    used = (await kvs.get_value(key)) or 0
    if used + n > FREE_LIMIT:
        raise QuotaExceeded(feature, used, FREE_LIMIT)
    await kvs.set_value(key, used + n)

Month roll-over is a string key by year-month â€” no cron, no migration, no drift. Pro tier flips a flag and skips the check entirely.

Tests

Six pytest tests, asyncio_mode = auto in pytest.ini. Coverage:

Router rejects unknown feature
Each of 4 features short-circuits cleanly in dry_run=True
Quota raises after limit, allows under

[pytest]
asyncio_mode = auto

That tiny config line is the difference between "6 tests pass" and "6 tests error: missing event loop". Learned it the hard way.

Pricing model

Free: 100 threads / month
Pro: $19 / month (5000 threads metadata + 100 LLM summaries)
Pay-per-result add-on: $0.50 / 1,000 thread metadata, $0.005 / summary

Apify handles billing. I handle code.

What I would do differently

Webhook trigger â€” right now unread_digest runs on demand. A scheduled trigger + Slack/Discord delivery is the obvious next product.
Label-level rules â€” reply_metrics is global. A per-label SLA matrix would be more useful for sales teams.
Multi-account fan-out â€” one run, multiple OAuth tokens, one combined dataset.

Code

Repo: https://github.com/foxck016077/apify-gmail-inbox-intel
License: MIT
Actor manifest: .actor/actor.json + INPUT_SCHEMA.json if you want to fork

If you build automation workflows alongside this kind of inbox tooling, I keep a small Gumroad with practical n8n templates (lead auto-responder, content pipeline, competitor monitor): https://foxck.gumroad.com. Not required, just adjacent.

Happy to take feedback on the OAuth-only design â€” was there a reason to go full 3-legged that I am missing?

📚 Part of the Apify Gmail Inbox Actor — design notes series.

Forem: foxck016077

Apify Actor pricing patterns: Free tier + Pro + Pay-per-result — designing for indie buyers

Free tier is trust validation, not generosity

Pro is predictability, not "more buttons"

Pay-per-result is for the elastic edge

Pricing is a product of architecture

What "good pricing" actually means

Related

Open-sourcing an MIT Apify Actor in 24 hours — a build log

Step 0: cut scope

Hours 0–6: execution path first

Hours 6–10: OAuth timing

Hours 10–14: quota lives in the main flow

Hours 14–18: the unglamorous cleanup

Hours 18–21: README + MIT license

Last 3 hours: stranger's-eye review

What I'd say to a past me

Related

Per-feature quota in Apify KeyValueStore — no DB, no cron, no drift

Related

Why I picked refresh-token-only OAuth for a multi-tenant Apify Actor

The operational reality of an Actor

Why not "platform-managed" delegated access

Refresh-token-only as an observability win

Privacy posture

Three questions before you copy this

Closing

Related

Gmail OAuth client_id is not a secret â design notes for self-host Actors

Public identifier, not sensitive credential

Where the security budget actually goes

Common mistake: budget in the wrong place

What this means for multi-tenant Actor design

Self-host does not exempt you from threat modeling

Documentation pattern

Open-source carries extra weight

Closing: stop asking "can I hide it"

Related

An Apify Actor for Gmail inbox analytics â refresh-token-only OAuth, async router, per-feature quota

Why an Apify Actor

Design decision 1: refresh-token-only OAuth

Design decision 2: one async router, not four actors

Design decision 3: quota lives in Apify KVS

Tests

Pricing model

What I would do differently

Code