Launch HN: Lago (YC S21) – Open-source usage-based billing
131–140 of 144 posts
Re: Launch HN: Lago (YC S21) – Open-source usage-based billing
#132I am sorry to be that guy but why ruby? I feel that Lago is a good idea but ruby usage is in a downward trend and few developers want to invest time in ruby projects these days. Was node or python considered?
Re: Launch HN: Lago (YC S21) – Open-source usage-based billing
#133Earlier 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?
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 n…
That is - offer your code to your customers under the agpl, not necessarily back to Lago or the community. But, since your customers get the code under AGPL, they in turn are free to distribute it. So, in practice, going that way - it generally makes sense to just open it up, and contribute back directly.
(imagine your only customer is IBM, or some other big company - they might not care/have an interest in re-distribution of the AGPL code - so you could be compliant (offer source to IBM) - but effectively closed off from the community).
Re: Launch HN: Lago (YC S21) – Open-source usage-based billing
#134Exciting to see the progress of Lago and the attention being given to the challenges in the SaaS billing world. We're also working in the billing space with a complementary tool, Tier ( https://github.com/tierrun/tier ). Although we currently do not support Lago directly, it's exciting to see more options emerging. Their content marketing has been particularly impressive on HN and in general. With metering, entitleme…
Want to say Thank you for putting all artefacts online. Same applies to Lago!
Admire your focus on Stripe and beginner friendly approach from the day one
https://github.com/tierrun/tier/blob/main/pricing/schema.jso... https://docs.tier.run/docs/resources/mapping-to-stripe https://github.com/tierrun/tier/wiki/Stripe-Glossary
Lago backend is built with Ruby and GraphQL ... which is kind of deal-breaker for me. No time to invest in Ruby ecosystem. I'm only using opensource products which I can fork and debug later on. https://github.com/getlago/lago-api/tree/619a7a53f98d9a19908...
Lago is much closer the production ready however. Solid stand-alone tool already.
Tier like projects gives me hope to give SaaS user better embedded billing experience and more control in the future.
My biggest scare - successful open source projects are getting too many extraline of code overtime.
Ex. Sentry with 25+ containers inside https://github.com/getsentry/self-hosted/blob/48c855aa3def45...
Re: Launch HN: Lago (YC S21) – Open-source usage-based billing
#135I am sorry to be that guy but why ruby? I feel that Lago is a good idea but ruby usage is in a downward trend and few developers want to invest time in ruby projects these days. Was node or python considered?
Re: Launch HN: Lago (YC S21) – Open-source usage-based billing
#136Earlier quoted context omitted.
I’m not suggesting it’s easy, but the trick is to play with pricing a lot in your early days while learning what those costs are. Start a little higher than you think you need - it’s easier to adjust down later than go up. Outliers can be caught with a small amount of code (hey, Slack me if a customer who I thought would use this thing once a day uses it 20 times so I can reach out to them to learn more about how the…
Question: would you then put Unlimited* with an asterisk: "unlimited within reasonable bounds"? I would feel it unethical to claim unlimited as a blanket statement.
Re: Launch HN: Lago (YC S21) – Open-source usage-based billing
#137Earlier quoted context omitted.
The job post includes a range: $50K-100K and the location is set to "Bogota / Paris". I had researched compensations in these markets and the range seemed relevant. We definitely pay competitive salaries, place the bar quite high and adjust it based on the candidates we meet.
Interesting. Wouldn't have thought a range including 50k/yr would be competitive.
Re: Launch HN: Lago (YC S21) – Open-source usage-based billing
#138Earlier quoted context omitted.
I'm a big fan of usage based billing. It lets small users have small bills. Per-seat pricing has always felt annoying to me. Ideally you want everyone at your company to be able to access the tools that everyone else uses (you don't want to create a bunch of second class citizens), but that gets really expensive really quickly. So per-user-per-month has never felt great to me. That said, usage-based billing is confus…
Small bills are cool, until it's too small. I remember having to negotiate with Stripe the removal of their lowest limits. The quantum of unit I was billing on my cloud platform was such that you could consume just enough CPU and storage to end up with a $0.01 invoice at the end of the month. It was impossible for Stripe to process this payment. IIRC their lowest limit was $0.50 or $0.10. I guess they had this limit…
My most recent Rackspace bill was $0.05. I don't even remember what I'm using it for any more, but it's not worth it to check out.
My last Pulumi bill was $0.86.
Re: Launch HN: Lago (YC S21) – Open-source usage-based billing
#139Earlier quoted context omitted.
Question: would you then put Unlimited* with an asterisk: "unlimited within reasonable bounds"? I would feel it unethical to claim unlimited as a blanket statement.
Yes, as AnhTho_FR said, some * notating “fair usage” or “unlimited for advertised use-cases” gives you a fallback in the event of a dispute. It ultimately depends on what you’re selling and who your customers are. If a customer is legitimately consuming way more than planned - so much that it’s not compensated by other customers who use it way less - then just reach out to them and talk person-to-person about why the…
Just set a limit then instead and don't market it as unlimited.