You are right! The issues usually happen when you add more complexity (tiers, discounts, credit notes, coupons, prepaid credits). Also, what I find very tough is that this is not a « one stop shop »: every single company has it’s own definition of what should be included or excluded from the MRR. I am pretty sure you never end up on an universal definition
You’ve got plenty of paid options with Stripe, but here’s the catch: trying to match what you see in the Stripe dashboard with exact cent accuracy using queries is a total headache. in addition, it would be simpler to add an option to pull that data via an API call.
Yes! And ARR = annual recurring revenue. In addition to other saas metrics like usage revenue that is pure consumption based and sometimes calculated differently
But Amazon uses a custom homegrown usage based billing, not relying on Stripe Billing. This is why Lago exists, to offer a flexible usage-based billing architecture for companies offering usage based or hybrid billing without having to build everything on their own.
We're diving into creating an alternative to one of Stripe's key services which is billing. Especially focusing on areas where Stripe struggles, like mixed or usage-based billing models. We do offer a great UI/UX ;)
We're diving first into creating an alternative to one of Stripe's key services which is billing. We especially building billing on areas where Stripe struggles, like mixed or usage-based billing models.
What's a fair price for a budget-friendly hosted version? Lower upfront cost, or maybe a revenue share? We've aimed at enterprise deals for the paid edition, keeping the open-source version widely accessible. Keen to hear your thoughts on adjusting our pricing.
What's a fair price for a budget-friendly hosted version? Lower upfront cost, or maybe a revenue share? We've aimed at enterprise deals for the paid edition, keeping the open-source version widely accessible. Keen to hear your thoughts on adjusting our pricing.
(Lago co-founder here.)
I guess it depends on how complex your pricing and monetization process are (is it the same pricing for everyone or custom ; is it a simple subscription: or a is there revenue share, transactional pricing, usage-based, tiers ; is it self-serve or sales-led with a quoting system, do you have grandfathered plans, do you need to use other payment processors than Stripe - "Stripe Billing" is only usable with "Stripe Payments").
In some cases, it's "brain dead simple", in a lot of cases it ends up "being much more complex than it seemed".
I could add:
- metering
- relations with accounting/finance softwares
- timezones (if your customers are spread around the globe)
- proration
- payments and dunnings
When you don't understand the complexity of billing (revenue ops, top management or marketing), you often end up adding more and more complexity, and engineering teams have no choice. They have to build new billing features
The use case is tiny at the beginning but the complexity increases over time to be honest. The scope is never as narrow as you think at the beginning of the project. Libraries are great, they can help you implement faster, but if the company grows, you will need an entire team to build and maintain it
Not necessarily open source, but there are a lot of third party tools for accounting (netsuite, quickbooks, xero). And I would say they scale 100x better than an in house tool
Navigating this challenge involves the ever-changing boundaries of billing. Initially, you build a monthly billing system, only to find that your team requires a yearly one, which seems relatively straightforward. However, complications arise when you introduce usage-based billing, incorporating weighted values akin to storage, layered on top of a quarterly plan. This complexity is further exacerbated when custom billing structures are needed for negotiated contracts, adding another layer of intricacy to the mix.