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

#saas #productivity #architecture #buildinpublic

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.