DEV Community

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

Posted on • Edited on

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

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.

Related

Source: foxck016077/apify-gmail-inbox-intel — MIT, free-tier-first packaging, and pay-per-result pricing patterns for indie-friendly automation.

Reality check — I shipped the free actor described above with a $9 PWYW manual companion PDF on Gumroad (Freelancer Gmail Client Tracking Pack). Four days in: 0 sales, 1 star. Posted the funnel data and 5 corrections here — most useful counter-evidence to the pricing-pattern theory in this post.

Discussion question: When you price automation for indie users, how do you decide the breakpoint between free tier goodwill and paid sustainability?


Update (May 19): The Actor I picked PPR pricing for is live at apify.com/foxck/gmail-inbox-intel (currently free MIT — PPR planned once usage justifies). If you want the freelancer-specific companion PDF instead, it just switched from a $9 hard wall to pay-what-you-want from $1 — Day 6 of this whole open-build experiment.


Day 7 update (later May 19): I shipped a product pivot — the Gumroad listing above is now a Self-Host Bundle for engineers (full Actor source + docker-compose.yml + 5-min OAuth setup), PWYW from $5 suggested $19. The original PDF still ships inside as a bonus. Same URL.

Day 7 write-up with the funnel audit that triggered the pivot: funnel audit found 7 of 9 articles had no buy link, then I pivoted the product.


Sample report preview: Friday Triage gist — anonymized 10-thread example of the $99 Done-For-You triage output. Grounded in r/sales 1tdngew (49 comments on re-engaging cold prospects) and r/smallbusiness 1td0827 (60-comment thread, top reply at 61 score: "holding 50 open loops in your head").


More from the shop:

Read the latest checkpoint: Day 16 — +51 reader spike in 85 min, 0 sales


Day 18 — pbot v1 dev preview shipped

After 18 days of this ZERO-TEN cold start: $9 PDF killed at Day 17, pivoted to pbot — a one-click personal knowledge bot you install on your own machine. Talk to it from LINE / Telegram / Zalo on your phone.

v1 dev preview is real: 93 MB macOS .dmg packaged, 15k-chunk SQLite FTS5 queries in 0-3 ms, Anthropic real calls with source citations, daemon auto-start on boot. Day 18 deep dive: the 7-line bigram fix for Chinese search.

Join the pbot waitlist ($29 · first-100 get -30% → $20) →

Top comments (0)