Live data from Hacker News

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

news.ycombinator.com

71–80 of 144 posts

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

#71
post #55

Earlier quoted context omitted.

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

I saw that. I'm planning on open sourcing my business's licensing API this year (which also handles entitlements, but differently than Oso). Maybe we can chat once that happens. Would love to point customers to Lago more often (currently we recommend Lago for metering [0] when it makes sense).

Keep up the good work, regardless!

[0]: https://keygen.sh/docs/choosing-a-licensing-model/metered-li...

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

#72

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 rea…

This is definitely something we'd like to build in the future. For now, we focused on building the core billing features and giving access to the billing and usage data so that end users could leverage it in their own BI and data stack (tracking, revenue recognition, etc). The next step would definitely be to offer these kind of features: either through partnerships or internally with the help of the community. If someone is building a great product in this space, we're very interested!

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

#73

Congrats on the launch! Any plans to tackle Stripe Connect like functionality (platform / marketplace payments)?

What would be the use case for you and the reasons to leave Stripe Connect? We're working with one company to replace their Stripe Connect stack, but it really depends on the specifics of the use case. My email if useful: anhtho[at]getlago.com

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

#74
post #71

Earlier quoted context omitted.

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

I saw that. I'm planning on open sourcing my business's licensing API this year (which also handles entitlements, but differently than Oso). Maybe we can chat once that happens. Would love to point customers to Lago more often (currently we recommend Lago for metering [0] when it makes sense). Keep up the good work, regardless! [0]: https://keygen.sh/docs/choosing-a-licensing-model/metered-li...

Sure! My email: anhtho[at]getlago.com

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

#76
Happy Lago customers here at Mono, we we're able to "hack"our way to billing connecting a Kafka listener to n8n and orchestrate all the billing from n8n, rather than expending lots of time integrating. We did all the integrations in 1 week in a "low-code" environment without requiring any developer to work on in.

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

#77

Congrats on the launch! Any plans to tackle Stripe Connect like functionality (platform / marketplace payments)?

What would be the use case for you and the reasons to leave Stripe Connect? We're working with one company to replace their Stripe Connect stack, but it really depends on the specifics of the use case. My email if useful: anhtho[at]getlago.com

payfac flexibility (aka, no vendor lock-in) — requires an independent platform ledger (where payments have two legs: payee to platform and platform to merchant). Refunds and chargebacks may affect both legs :)

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

#78
post #15

I submitted separately [0] your blogpost "Open-source licensing and why Lago chose AGPLv3" [1]. I find this a refreshing and good read that counters the usual FUD so many people raise when hearing about the AGPL. In the article is mentioned Plausible [2] who also managed to create a great business this way, and in direct competition to Google Analytics. Well done. https://news.ycombinator.com/item?id=34773891 https:/…

Regarding this blog post, I don't understand how AGPL is a good fit for the first stated use case.

>Case 1: You fork our code to build your own billing system at your company. It’s awesome and we would be grateful if you could take some time to share your code as well, as it could help other companies. This is _strongly encouraged but not required_, as we understand not all companies can afford to do this.

And later in the quoted explanation of AGPL:

> "If you run a modified program on a server and let other users communicate with it there, your server must also allow them to download the source code corresponding to the modified version running there."

If you fork the project, your company's customers are communicating with your forked code. So are you required to publish your forked changes? Only required to share the fork with paying customers? Or as your desired case states, not required?

(In any case, Lago looks very cool. Thanks for pushing forward the conversation on open licensing!)

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

#79

I think this is going to be/already is a crowded space. SaaS companies are feeling the burn of layoffs due to per-seat pricing, so metered billing seems like a good alternative. Unfortunately, as a SaaS consumer, I despise it, as it's meant to be obtuse and hard to estimate, plus I have yet to see any SaaS/IaaS offer real spend controls like stopping the service.

I don't necessarily think that billing which is hard to estimate is good for anyone. For large deals I've seen this be a real turn off. Same with surprise bills. Ultimately if the service can scale billing in a way that their value scales to the customer (Datadog and Snowflake come close to this) then both the provider and the customer will be happy.

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

#80

If I have a marketplace (something like RapidAPI or Shopify, for example), can I use Lago to allow my providers to create custom pricing plans for their customers? Skimming the Lago API, I see that I can create all the parts of custom pricing plans, but can I group/separate them as well? As in, can there be pricing plans for company A with coupons for A, but company B has their own plans and coupons? Is that somethin…

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
Post reply on HN