It seems like they have things backwards. The small fry like me don't want to self-host, we want a managed solution. The big fishes have enough scale to self-host.
But a few years in we were doing substantial volume and we wanted to re-negotiate the contract. If we had Lago and could re-integrate with that, using it as leverage on a Stripe contract renewal, that could have been worth $3k a month, given that we were paying Stripe $30k per month in fees.
Our situation was a little different being retail rather than SaaS billing, but I could see a world where this makes financial sense.
We ended up talking to about 5 different usage based billing API providers and basically no one is interested in servicing the sub $1000 per month market which is where we will realistically be for the next year as we grow.
Additionally lago and other providers advertise "no revenue cut" and then always quote pricing as a percentage of revenue (which is technical not a revenue cut except your fee scales pretty linarly with revenue).
It's pricing genius to avoid the small, expensive to service, unprofitable customers (let Stripe lose money on those), and then they cherry pick the good customers once that have already scaled up at Stripe
If it does go places, I'm happy to pay the big fees when it gets big.
IMHO this is why Stripe is so successful - picking up the customers while they're small. I'm with Stripe because Adyen et. al wouldn't talk to me at $100/mo but Stripe would, and many years later I'm still with Stripe running a large multiple of that through them (ok, via Paddle now..)
They have open source / no support billing, so why wouldn't use use that? They also have an up to 50% discount for early-stage companies.
I know, cuz I am one.
I also looked at Stripe Billing for usage-based and it didn't meet my requirements either. (though I am using Stripe Billing with flat charges).
My exact use case is:
- I want to sell API credits upfront including for subscriptions (i.e. user signs up for $10/month of credits, they pay $10 upfront, and can spend $10 worth of credits). Stripe billing doesn't support charging upfront, for usage-based, they only bill after the billing period is finished. Some of my users have been gaming the system, canceling and not paying so that doesn't work for me. I believe Lago did support billing upfront.
- I want to freely mix subscription based and pre-paid credits. My users go over their quota one month, they don't want to upgrade their subscription to the highest tier, they prefer a one-off top-up. I need to control over which credit gets consumed first. Stripe billing and Lago both had issues with this, I can't remember exactly what.
- I wanted to support as many payment methods as possible, and particularly Chinese wallets for pre-paid credits (Alipay, Wechat). Lago has no plans to implement this, I was half considering implementing it myself inside Lago. I don't think Wechat and Alipay will matter much for B2B businesses.
- I'm also a huge fan of massively regression tested code, and Stripe Billing with its test clocks blows Lago out of the water here. Lago has no ability to walk the clock forward for subscription lifecycle testing. Though maybe this matters less if you have faith in the product, you can just expect to get the right callbacks on time.
I did notice that the Lago devs on slack took time to answer questions down to the deepest technical level. If I was running a B2B startup, I would probably try really hard to fit Lago in the picture, particularly at at time when stories of Stripe account bans are so prominent.
If the user cancels their subscription, I run it through the next payment period for their usage based billing period and then cancel it.
Also, this is kind of their thesis, isn't it? That developers want open-source software to do their billing, which they can modify themselves if they need certain features instead of relying on a proprietary provider like Stripe. Doesn't sound too outlandish to me.
If anything, the mind fallacy isn't the GP but on the commenters pretending that they love losing money. If we could pay $0 and get everything we want, we would. Everything else is just performative commenting to save face.
The fact that even Amazon has switched to Stripe shows this.
And that is not even getting into the PCI, PCI DSS, SOC, I and II, etc compliance soup of self hosting.
I’ve seen this sentiment a lot, especially from OSS veterans like rich harris (who ironically now gets his paycheck from VC money). On one hand I want to complain about it too and say that people should only build open software for the love of building and sharing, but on the other hand it costs a lot of money to exist in meat space and it seems counterproductive and unfair to expect people to build software I find useful (and most likely even profit off of myself) on nights and weekends and get paid in GitHub stars.
https://github.com/getlago/lago/wiki/Open-Source-does-not-wi...
It got a fair share of comments on HN as well https://news.ycombinator.com/item?id=37682684
I don't understand the benefit of OSS in Lago's context other than PR/developer goodwill.
It's a catch-22 when building in open source nowadays, so if this is the future of it with the benefit of things having better longevity and support, so be it.
I could be totally wrong but that is my understanding of some of these projects.
When open source started in the mid-70s, the ethos was: give software away for free. Money came in the form of university or corporate research grants, there was no business model. Only in 1998, the money came into picture once RedHat, MySQL, and many others started doing paid support and services on top of free software. And starting mid 2000s it became common to think about making money with open source, and that's because of cloud computing. In SaaS, the user does not know or care if there is open source or proprietary software under the hood, so it leveled up OSS, put it in the same game as the rest.
Why VCs like open source? (I'm a former ML engineer turned in-vest-er), well some of it is nostalgia in my case, I used awesome OSS software while in university like spaCy and i share the same values of community, transprency, giving back etc, and some of it is related to what the job of a VC is - makin' money.
In closed source companies, one invests a lot into sales and marketing. Developers generally don't like to be sold, they can't be sold they have to choose you/your product. So if a company manages to win the hearts and minds of developers, they will pull your software in to be evaluated by procurement for purchasing without spending millions in sales and marketing, it's more efficient as a business model. It's also a lot more defensible. Big corp can pur money into suits to sell their products, but you can't buy developer love, for that you need amazing DX and good dev rel. But making money in OSS is a lot harder than in SaaS. in SaaS people talk about product-market fit (find 5+ customers who use the same way, buy the same way, get the same thing out of the product - predictability so the VC gives money and scales sales). In OSS you've got the problem 3x: you gotta get to project-community fit (you measure GitHub Stars), then product-market fit (you measure downloads) and then value-market fit (you measure revenue, and the buyer might not be the same as the developer/user). Most amazing OSS products fail at the value market-fit section.
Most founders of OSS companies fail to extract value. Some of it is because it's so hard or because people feel like OSS should be "free software" that they postpone monetization. And then when they start to monetize it's too late. would you buy a cow if you've been getting the milk for free for years? The other reason they fail is they don't know how to do it. The typical 3 ways to make money with OSS are: support (you sell support and services -e.g. RedHat), open core (you sell propritary functionality - e.g. confluent, elastic) and SaaS (you sell hosting, tooling - e.g. databricks).
One simple way to think about it, based on the successful OSS companies I've see in, the free version of the product should have everything, all the bells and whistles that a single developer needs to get the job done. and the paid product has the extra features that are needed to get the job done as a team.
I love open source software and it pains me to see super smart founders and so many contributor put so much of their passion into building it but failing to scale it, commercial helps there, and failing to get rewarded for the hard work. But it's darn hard, it's like going against your nature, if you contribute to OSS and build OSS you care about community and want to give it for free. So making money with it, just thinking about it, makes you uncomfortable. And when people are uncomfrtable, they go do what they know, where their comfort is, and that is coding for most engineers. And that's how you end up with awsome OSS software with lots of cool features and a founder who postpones monetization so much for so long than at some point it passes the point of no return and that's how another promissing company dies, nobody wants to invest if they can't get their money back even if the product is really really cool.
Having to maintain my own payments stack (and PCI compliance) sounds like a massive distraction.
Tracking the edge cases around recurring payments, invoicing, pro-rated tier changes, and metered billing is hard! And Stripe Billing APIs aren’t the most fluent for many cases. It’s good to see new layers in the space.
(Disclosure: I founded Very Good Security & was the CEO for 8 years).
No? Didn't think so.
Lago is written in Ruby.
I found few other open source billing systems written in Java.
Anyone knows anything written in nodeJS?
On the other hand there are counterexamples about great intentions coming up from France. For example, Semmle [1] which was acquired by GitHub for performing static analysis over the repository. Inria [2] is great but the problem is not research but how to compete at the business level with American-like companies.
https://github.com/getlago/lago
I'd never thought I'd see Meme-ification of technical docs.... oh god
I guess you entered the industry after 2015? Even the most technical analysis like the Jepsen Reports which evaluated the technical claims of Cassandra DB etc used lots of memes between the technical bits. Presentations always had cat/dog pictures in them etc.
They always been, in different forms. I am glad to see them too, harmless and signal IQ/EQ, taking anything too seriously is not a good thing.
But in no way does this signal IQ/EQ. It's just a personal preference
> Oh, we have to put our brand on top.
Except, it ruins the whole meme.
If you search for recursion. Google asks did you mean recursion.
(Disclaimer - I work there)
Billing, invoicing, payments, entitlements, subscriptions.
All different things.
7M was seed, raised in 2023 according to crunch base.
Sounds like they aren't trying to be an entire stripe replacement (from the last paragraph of the linked article).
Anyway an interesting story of a successful startup pivot starring a passionate HN post.
https://www.ycombinator.com/companies/lago/jobs/RvvzKuM-sr-b...
Intuitively you might think that the EU, with all of the freedom of movement laws, might make this unnecessary, but it doesn't. At least as far as I know, it's no easier for (say) a German company to hire someone in Italy that is is for them to hire someone in Japan.
I am not a Stripe customer but I interacted with it as a normal user (e.g. KYC) and was impressed by their UX/UI, an area where open source projects doesn't excel at all. UX/UI is really hard to grasp.
Stripe customers look for a strong finance platform, they don't care if it's open source or not. Also, from the business perspective you need to have a hard drive to manage a company like this.
Yes we’d love feedback on our UX/UI as well!
I remember when I last time looked into lago, there was no versioning and the json configs were unintuitive and difficult to use. (I think it was also impossible to create a metered usage with a fixed one time fee$
Event-based: if you can track it, you can charge for it;
I see this being useful for usage based pricing.