Rafsark

What do you mean? "Thinking about monetization too much"?

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

That’s one of the options, yes. Chartmogul does an amazing job at ingesting and retrieving revenue data from stripe

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.

If you spotted it, it means than images have a greater impact than words.

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".

Related threads: - "Why Stripe doesn't use Stripe Billing": https://news.ycombinator.com/item?id=33191307 - "Stripe's real pricing: a primer" : https://news.ycombinator.com/item?id=33920019

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

Was it a basic subscription model or have you faced challenges with taxes, usage-based components, entitlements, grand fathering?

Even if you find that guy, you'll have to find 20 more in the next 3 years if the company grows