xenial-blackā¢2d ago
Hey everyone š
Hey everyone š
Iāve been thinking about how we, as Apify users, pay for actors and APIs, and I wanted to throw an idea out there. Right now, it feels like some projects fit best with subscription-style pricing (predictable monthly plans), while others really need pay-per-usage (since workloads can spike or stay small).
What if Apify offered a hybrid model?
A base monthly plan (so costs are predictable and budgets are easy).
Extra usage-based charges when we go over the included quota.
This way:
Casual users donāt get scared off by high upfront commitments.
Power users still have room to scale.
Apify also gets more stable recurring revenue instead of just spiky usage.
It feels like a win-win predictable for users, flexible for growth, and sustainable for Apify.
Curious what others here think would you prefer a pure subscription, pay-as-you-go, or this hybrid approach?
7 Replies
The problem is that there already is Apify subscription and overages on top of that. That is why we are reluctant to have another billing subscription system like rental on top of it, it is really hard for users to manage. But we are thinking about possibilities.
Instead of a subscription it could be a minimum spend, or creditc packages, per month.
Either way, something resembling a hybrid is a must for me to keep focusing on Apify. RapidAPI has these models and it just works much better.
What is your main worry, that your revenue will jump up and down a lot every month? What we see is that once you reach some popularity threshold, even without subscriptions, the usage stays within 20% from previous month so it is quite stable. customers already have subscription on Apify so they are more likely to use the credits than if it were just pure pay-as-you-go
customers already have a subscription on apfiy because that's the business model you picked. For communtiy actors, a subscription per actor would be much more attractive. The average revenue per user is much higher if there's a minimum up front, it's more predictable, recurring-revenue is more valuable
i understand that you might want to stick to your business model, but it's not very interesting for me as a business to have 100s of users that pay met $1 per month, so a hybrid model, or a minimum spend, could be a good comprimise
This would all be much easier to measure if we had some actual usage insights from our users. The anonimity and limited insights don't help
Yeah, I asked the team to collect data on how the revenue fluctuates for different models for various income bands. In high-level, we don't see a big fluctuations even without rental model
I understand the concern about adding complexity with another subscription system. However, I see it a bit differently. The community's strong reaction whenever deprecating the "Rental" model is discussed shows how valuable recurring revenue is. The issue is that the current Rental model is too limited.
Hereās my perspective on the current models and a potential solution:
1ļøā£ The Lost Opportunity of the Current Rental Model:
The Rental model has the core of what makes SaaS great: recurring revenue (MRR). The problem is its current inflexibility. For example, a $30 monthly rental at a $0.004 PPR price caps a user at 7,500 results. If they consume a million results, I face a massive opportunity cost.
However, if we could offer multiple subscription tiers with different limits (e.g., $30 for 10k results, $100 for 50k results), we would capture that lost opportunity. This is how modern SaaS pricing works. Plus, it's a known business reality that most users never hit their limits, which makes the model highly profitable and predictable for creators. The current system forces a choice between predictable but limited income (Rental) or scalable but unpredictable income (PPR, PPE), when we could have both.
2ļøā£ The Problem with Multiple Confusing Models:
You mentioned avoiding complexity, but having four different models (PPE, PPR, Rental, PPU) is arguably more complex for both users and creators than a single, flexible hybrid model. A unified model where the creator can enable pay-as-you-go, subscriptions, or a combination (e.g., a subscription with a usage quota and overages) would be simpler and align with industry standards.
3ļøā£ PPE Tiers (Bronze, Silver, Gold) are Misaligned:
This is a key point. The current PPE model seems to benefit Apify's platform tiers more than the value a user gets from a specific actor. A "Gold" tier user and a "Bronze" tier user could both spend just $1 on my actor, and it might even be cheaper for the Gold user. This doesn't make sense. Pricing should scale with the value and usage of the actor itself, not the user's general Apify subscription level.
4ļøā£ The "Zombie User" Incentive Problem:
If there were a proper subscription model (like the old Rental but with limits), the so-called āzombie usersā would no longer only benefit Apify through their platform subscription. They would also generate predictable revenue for creators. Letās be honest this is the real strength of any subscription business: recurring revenue with expiration. Thatās why you almost never see ārolloverā subscriptions where unused capacity accumulates, because predictability matters more than squeezing every last unit of usage. A subscription per actor would bring that same stability, creating a healthier balance where both Apify and creators benefit equally from low-usage but long-term users.
A Final Thought (The "Win-Win"):
Ultimately, Apify is an intermediary platform. Your long-term success is tied to the success of your creators. By providing creators with the tools to build sustainable, high-value SaaS-like businesses (like robust subscription models), you attract more talent. More high-quality actors will attract more high-value customers to the Apify platform, creating a powerful flywheel effect for everyone.
I believe simplifying to a flexible, hybrid model isn't just about adding a feature; it's a strategic move to better align the platform with its creators and unlock much greater shared growth.
Agreed on all points, what you're describing is basically Rapid's model, which works really well