Live data from Hacker News

Launch HN: Lago (YC S21) – Open-source usage-based billing

news.ycombinator.com

61–70 of 144 posts

Re: Launch HN: Lago (YC S21) – Open-source usage-based billing

#61
Congrats! We built a usage-based telephony (voice & sms) billing system for our customers and appreciate the pain. Not to take anything away from your launch, but founders / product managers should carefully consider if usage-billing (even with a tool like Lago) is best for your business and customers.

We started as usage-based then learned a few years in (once we understood customer usage trends - key) that customers would gladly pay ~20% MORE per year for unlimited access because the customer wanted a predictable bill. We essentially rode the same trend of pay-as-you-go mobile to unlimited plans.

Later in our history we found investors (and our accountants) liked the predictability as well. It's easier to show "up and to the right" when not dealing with a few large customers varying down in usage in one quarter (even if the business was on the upswing).

One-size doesn't fit all -- usage billing has its place for sure -- just carefully weigh your model as it's a huge lift to flip it midstream.

Re: Launch HN: Lago (YC S21) – Open-source usage-based billing

#62
Congrats on the launch, as a growing and open-source startup ourselves, we are eager to switch to Lago as soon as our stripe fees are gonna become a PITA which I expect to be in the near-future. The product looks amazing and the API seems super well-designed!

Re: Launch HN: Lago (YC S21) – Open-source usage-based billing

#63
post #29

Earlier quoted context omitted.

Yes. AGPL is a great choice and counters SaaS companies that are trying to grift and abuse open-source with a modified competing product without contributing back.

I always get confused with AGPL and seems to have differing opinions online, so wanted to ask here. If I use Lago in my app, and don't change it all, do I need to opensource my entire application?

The short answer is "no". The high-level concept of AGPLv3 is to prevent someone who'd like to re-sell the OSS company's features (billing in our case). For instance, let's say you're a vertical SaaS like Mindbody, selling software to yoga studio owners so that they manage their business: scheduling, payment, and billing. If you use Lago to build your own billing feature (and sell it as part of your product), you'd need to either buy a commercial license (we call it "Lago Embedded") from us OR open source your code. Let me know if you need more clarifications!

Re: Launch HN: Lago (YC S21) – Open-source usage-based billing

#64

Earlier quoted context omitted.

I always get confused with AGPL and seems to have differing opinions online, so wanted to ask here. If I use Lago in my app, and don't change it all, do I need to opensource my entire application?

As far as I understand it there's no legal precedent, so we're not completely sure. Some say calling an api means it's part of your application, meaning you need to open source your app. Some say that that's not the case. I think this unknown is why the license is banned in some companies. I think what matters more is how the creators of the software intend the license. In case of Lago it's clear they want you to use…

That's on point. A "proprietary billing service", or a service that includes billing in the value proposition in general: whether you're a vertical SaaS, an accountingtech, or a payment processor.

Re: Launch HN: Lago (YC S21) – Open-source usage-based billing

#65

Brad Cox laid out a scheme similar to this in hopes of solving the software crisis, in his 1995 book Superdistribution. Now, it wasn't really technically feasible when software was local and native, but in the cloud era it makes a lot more sense. I've personally felt the pain of creating a bespoke multitiered billing system so I appreciate what you're trying to do here, good luck!

Thanks!!!

Re: Launch HN: Lago (YC S21) – Open-source usage-based billing

#66
This is very cool! We just built our own internal billing tool for our company after bad experiences with Recurly and ChargeBee. We are B2B and B2E and ChargeBee/Recurly felt very clunky when used for enterprise billing — specifically around usage based billing, discounts, and multiple geographies.

The billing part was easy to build (though of course we under-estimated the effort by 10x), but the reporting is the really tricky part. Revenue recognition, plus simple things like correctly tracking upgrades/downgrades vs expansion/contraction when someone changes plan mid-month.

Is this something that Lago does now or intends to include? I could not see it in the docs.

Re: Launch HN: Lago (YC S21) – Open-source usage-based billing

#68
post #55

Earlier quoted context omitted.

Thanks Arnon! I often keep sharing your blog post on entitlements: https://arnon.dk/why-you-should-separate-your-billing-from-e... !

This is a great answer to a question I get asked a lot. Thanks for sharing!

That's one of the reasons why we decided not to build "entitlements" ourselves, and prefer to partner with other "pure players" (or recommend to build internally if it's really specific). We've been working with Osohq.com (open source as well) as there's a great product and DNA fit: https://doc.getlago.com/docs/integrations/entitlements/oso

Re: Launch HN: Lago (YC S21) – Open-source usage-based billing

#69

Earlier quoted context omitted.

IMO starting with "first of all we were there first" kind of sets the tone for the whole message. Here's how I would have written the same message: Hi! Lotus has a great product. We should know, as they reached out to us for inspiration before. Our team has prior experience building billing engines, so we have a very good understanding of the space. From a product perspective, our coverage is more extensive. We provi…

(Lago co-founder here) Thanks for your message Louis, we always welcome genuine and actionable feedback and appreciate the time you invested into writing an example!

No problem! If it's helpful I'm glad. I do believe the original message wasn't meant to be snarky/arrogant at all, it just read that way. Maybe it reads a lot better in French! :)
Post reply on HN