How do apps manage user credits/ features nowadays?
This seems to be a very common building block for apps, but I can't find popular solutions -
- An app has registered users
- Every user can have different types of credits, points, enabled-features, used-promo-codes, campaigns etc...
- Different parts should behave differently according to those
Sure, we can manage all that data in a DB and write lots of custom code, however it becomes a big block to design, refactor, migrate schema versions, manually resolve issues....
To clarify the question lets simplify to one use-case -
"Credits Management" -
- Upon purchase, user gets 1,000 credits of type "paid-credits" to be used in the app. These don't expire.
- Upon promo-code-activation, user gets 200 credits of type "promo-credits-feature1" - only to be used with "Feature1" of the app, and those expire after 1 month.
- User spends 200 credits on Feature1
- User is not satisfied, asks for refund. His "paid-credits" are not used yet, so he qualifies for a no-questions-asked refund.
- Upon server-side usage of Feature2, the backend needs to verify the amount of available credits (possibly "reserve X credits" for an activity), log the usage of the credits for traceability (such as an invoice breakdown) etc.
I would expect some existing solution to offer this as a service with an API. Do CRMs have anything to do with these things?
Is it "too simple of a problem" that everybody manage in their DB and don't make a big deal out of it?
It will be nice to hear what others are using and some insights about this.
Trending on Indie Hackers
Hey there,
I’m building keila.io, an Open-Source Mailchimp alternative. For Keila I’m also building a managed SaaS version which is based on credits. I chose a very simple approach: Users can use the app for free, up until the point that they need credits – i.e. for sending emails.
Then they can decide to get a subscription which will give them credits. Subscriptions can’t be refunded.
I find that this model is very fair to both users and developers. And it would make it very easy to handle promotional credits because credits never need to factor into the decision whether something can be refunded or not.
If you’re curious how I’ve implemented this, you can check it out on GitHub
My guess is that most products do implement their own credits management from scratch.
Maybe after an initial period with real users, it can be limited to a small enough scope and maintain a custom implementation that is tailored to the product.
However, it still feels like such a standalone block - that shouldn't be reimplemented over and over again.