Rafsark

That's true, but wishing a birthday at the right moment depends on the timezone. It's not just about the date itself, it's about the interactions other people have with this date

Completely true. I think the main point of your comment is about "presenting that information contextually to customers". You often have to make choices when you decide to bill your customers, and those choices have to be crystal-clear to your end users. When I was working for a neo-bank, 50% of the complains was about billing not being clear, and timezones was one of the top reasons.

Don't have much information about them, but it seems that we are API first while they are focusing on no-code (from what I understand from their homepage). The common path would be that we both have a UI to let non-tech users handle billing actions without engineers.

You are totally right, that's a good catch. Just changed the text color to white! Thanks a lot for your feedback

We put a lot of effort into the website and its messaging. This helps users understand how billing works, as the complexity of the features behind it can be difficult to grasp. To help, we often explain the problem and the solution. Glad you like it!

That's totally doable. You can simply create a price plan per customer, and call the subscriptions api to assign a plan to a customer. In addition to this, you can create a basic coupon, but override the value when assigning the coupon to a customer. Everything you described in your comment is totally doable with Lago API

Thanks! The space is becoming more and more exciting. Many players will emerge in different verticals, creating a great impact. Companies will be able to price, invoice, and track usage with greater precision.

Hi Kiro, I don't consider this an impudent response. We strive to base our answers on facts, from both the team and product perspectives. We tried to detail differences from a product point of view. We respect everyone in this space, including established vendors and newcomers. They all have a positive influence on our product, pushing us to deliver faster with higher quality.

You can still use Snowflake + DBT to track usage. However, this won't cover billing use cases. On top of this, you could need to create invoices, trigger payments, handle coupons, and issue credit notes. Many customers use warehouses to track usage and send usage-based HTTP events to Lago. This is the first step towards a full consumption-based or hybrid billing model. Ensure continued revenue and customer satisfaction by covering the entire billing, pricing, and invoicing workflow (not only aggregating usage)

Thanks! We cover all types of SaaS companies' billing. We often say that if you can track it, we can bill it! We cover subscriptions, hybrid, pay-as-you-go, and per-seat pricing models. We believe that the future of billing is hybrid - a mix of all the above. We've seen many missed revenue opportunities from companies that weren't able to price overage on top of a per-seat or pure subscription pricing (often because it was too hard to build, either internally or with existing vendors)

In our opinion, the future of billing is hybrid. This means customers pay a platform fee (a subscription) but don't face blocks for exceeding their plan's limits. Offering multiple plans with appropriate entitlements related to the feature set is still possible. However, blocking usage instead of billing for overage represents a lost revenue opportunity. Most customers won't upgrade, so we recommend allowing them to pay for overconsumption on top of the base fee.

Hi,

First of all, we launched our open source billing repository months before they did. In fact, they even reached out to us for inspiration. This could be related to the fact that our team has prior experience building billing engines, so we have a better understanding of the space.

From a product perspective, our coverage is more extensive. We provide more advanced coupons, usage-based components and billing use-cases. For example, we offer credit notes and refunds, small examples that are not listed in their API. Our product covers more billing edge-cases and deeper features.

Finally, we have customers in production. Our top user is invoicing 5M customers a month, which might not be the case for them.

To conclude, I would assert that we are more advanced.

We have a growing number of requests for this use-case, but we try to focus on billing right now. However, I can promote Formance (https://www.formance.com/) here that can help on this vertical. They are YC folks, and tackle the use-case of collecting fees and splitting payments. And it's also open source! Hope this helps

Thanks for the kind words. At Lago, we want to break the notion that billing is always a "buy or build" option. Billing can be so different between companies that it may require a custom setup, infrastructure, and model. Furthermore, the "buy" options available are often not scalable enough for large companies.

With our open source version of Lago, we offer: - Fair pricing: scale your billing as your company grows - Composability: build the pricing/billing you have in mind, without the limitations of vendors - Participative approach: contribute to the entire billing engine so other companies can benefit from it.

Thanks, we're excited to have you on board! We've had some requests about billing for marketplaces. Currently, Lago is designed to bill subscriptions with embedded fixed fees and usage-based fees, resulting in a consolidated "end of period" invoice. Marketplaces, however, require immediate invoicing with a different logic. We have a product vision dedicated to SaaS for now, but this could be a use-case to tackle in the future.

Thanks! We're big fans of Plausible and appreciate you mentioning them in your comment. We wanted to be transparent about why we chose this license. Our goal is to create a sustainable open source product, both in terms of quality and vision.

Yes, there are many differences between Stripe and Lago. Here are some of the most common:

Lago is completely agnostic of payment providers, meaning you can use any payment service provider (PSP) with it, whereas Stripe requires the use of its entire stack.

Lago is event-based, making it easy to ingest a high volume of usage-based components. This eliminates the need for users to manually bill their own usage-based billing aggregation on top of Stripe.

Lago is open-source, so there is no revenue taken as a cut. For its fully cloud-hosted version, Lago prices a platform fee and tiers on usage-based events, making it more scalable for high-volume companies. Additionally, its open architecture allows for full customization to fit your needs.

In my opinion, the future of billing lies in a hybrid approach. Former subscription- or per-seat-based models were too restrictive. Subscriptions with capped features prevented users from upselling and generating more revenue. The gap between the base subscription and upsell was often too large.

I agree that usage-based billing can be difficult to predict revenue from. We don't think companies will switch entirely to this model. However, the hybrid model can be beneficial for both customers and vendors. Companies can charge a base platform fee and then charge for overage instead of blocking it. This could increase revenue for companies that currently use subscription-based billing.

Hi Rabidonrails, We have decided to launch an official HN campaign for the beta release of Lago (https://www.getlago.com/beta). This Beta covers the full range of billing features (credit notes, bill on customers' timezones, invoice grace periods...) and we believe that our product is now suitable for a wider range of users and use cases.

Our previous articles focused on billing-related content. They discussed various aspects of billing, such as Stripe fees, alpha launch, and various features.

Hi there, I'm Raffi, one of the co-founders of Lago (Billing API). I think this dilemma is amplified with specific topics like authentication, permissions or billing. Even if you come with a home-made solution that took you a month to build, it's a month that you've not dedicated building your own product. The second reason is because they require a lot of maintenance. Building a first version is never enough, especially if you have a sales or marketing team with a lot of imagination/needs. When we built a billing engine for a fintech (Qonto, that is now an European unicorn), the home made billing system took a month or two to develop, but it became a monster: iterations every month, new features asked by non tech users, new behaviors, bugs. The team of 2 engineers working on billing ended up being a core team of 12 people. We switched from backend engineers to billing engineers (that is not particularly funny when it's not your core product).

Again, it depends your needs and the complexity required by your business. Happy to discuss that deeper if needed.

Value first, money comes after. I do agree with your comment!

At least, they should find another revenue streams. Some companies only price per seat while their customers share seats with a shared-password tool. We all do this. Having addons and other revenue streams is definitely a must have, although you are not fully usage based

Definitely recommend Windmill.dev!

I’m Raffi from Lago. Frankly, Stripe is a awesome company. They’ve built amazing products, including Stripe Payments (the blog post starts with this exact same statement). When it comes to billing, we do believe we are creating a better solution, especially for companies having complex billing (usage based, for instance). At least, we offer a new solution to prevent additional % fees on revenue, vendor lock-in and rigid billing solution by creating the tool we would have loved to use.

We do not bark up the wrong tree, but try to give our point of view about the perfect billing system

I do think most web3 founders are newbies, but somehow you need to be very passionate about the space...

Totally aligned with this. It takes about 2 weeks to implement (if you treat this as a proper feature), and it saves so much time after.

Some teams often say that it's not necessary before PMF, but I'm wondering how fast they ship without DS

Interesting comment. I feel like all engineers having a DS in past exp don't want to get back to a company without one. I had this feedback from several FE engineers.

Somehow, you don't know how painful it is until you have a company having a proper and clean DS.

You don't need to over eng it. Just a basic one is perfect before PMF

Can you test again, we made an improvement and should be better. Thanks again

I can see a lot of drawbacks if you don't have one. But a lot of early stage don't produce DS before Product Market Fit. Our design and FE team love to have it for several reasons: - Design consistency - Boost productivity when implementing a feature - Onboarding new teammates

We build a DS from scratch since the beginning, and we feel we saved a lot of designing and engineering time. Releasing new features has been pretty smooth thanks to it. It took about 2 weeks to implement with basic components and it gives us consistency when designing/specifying a feature. But I totally understand what you say. It's not necessary to build a startup reaching PMF.