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

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

You can add taxes and negotiated contracts to the list tbh

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.

What's your vision? Can AI handle revenue prediction and billing engineering tasks? Both? How?

How do you know in advance it will grow into a unicorn? I tend to agree with you, but that's a shame to have a team of 30 engineers working only on billing, even if you are a unicorn.. I would prefer to have them working on my product

I think billing, taxes and entitlements are 3 different products, with obviously strong relationships. I would rather give the advice to rely on a third party tax tool that is connected to the billing engine instead of the "all in one" if taxes are too complex. Otherwise, just use the basic tax codes of Lago's billing engine

Could you explain how? I know temporal has not built the billing engine themselves, so wondering how the tool can help with this..

Marketing teams can sometimes miss the mark on this one. There's a misconception that improving billing is as simple as launching a new marketing campaign, but that couldn't be further from the truth. Billing is a multifaceted aspect of engineering and business operations, and those who solely focus on it often prioritize following industry trends over gaining a deep understanding of the economic intricacies within the company.

It's crucial to bridge this gap in comprehension for more effective decision-making and strategy alignment between the marketing and billing departments. By doing so, we can ensure that both teams are on the same page and working together seamlessly to drive the company's success.

This is completely true. Taxes, entitlements and billing can be 3 different products. I don't understand how people think it's a 3 week effort. Avoiding this separation can lead to a messy setup down the road.

Timezones are not hard to build. It's indeed the interpretation of your app and the display to your end users that are hard to manage. Think of your birthday: it's not hard for you to set a datetime at your current location to define when your birthday starts. But the birthday wished from your friends might changed based on the interpretation they have and where they are located

Indeed, this cannot be a solution for most of the business out there, as date and time are tied together to ingest a certain event. But this could be an easy fix for some businesses

What would you expect as a fix? How do they know about the timezone you are currently on? Not an easy fix in my opinion as they have to be aware of your timezone (or ask for it) anytime you post

GMT+12, which only covers two uninhabited American islands

New Zealand users are now mad at you :D