I tried to use it for a new SaaS product - but their plans start at 3000$/mo.
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.
I see your point, but I think this might work for them. At my previous place we started on Stripe it was really nice to work with, cost nothing in absolute terms because we had few sales, easy to integrate.
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.
Got trapped by the same thing. Usage based billing is a huge pain point for us we were really excited by lago but dont want to self host infra if we can outsource it.
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).
Take a look at https://revenium.io (full disclosure: I'm co-founder/cto.) We are a fully hosted solution with a free/developer tier and plans that start at $19/month. We also have a self-hosted option.
This is actually a space I’m exploring. Would love to chat about your use case if you’re interested. Shoot me an email at chris. Domain name revenuehq.com.
We are billing more than $1000 a month :). The providers didn’t want our business for less than $1000 per month (at a heavily discounted time limited price).
We talked to this many providers because it’s a huge pain point for us and the thing we hacked together was inadequate for tracking usage.
This may be true in the most technical sense but it's a pointless observation. There are of course plenty of big businesses now so it's a perfectly rational business decision to target those big ones first. Because they were small 5, 10, 50 years ago is completely irrelevant.
This suggests their target customer are the Stripe whales spending more than $3000 a month on fees.
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
What's a fair price for a budget-friendly hosted version? Lower upfront cost, or maybe a revenue share? We've aimed at enterprise deals for the paid edition, keeping the open-source version widely accessible. Keen to hear your thoughts on adjusting our pricing.
100$/mo? I would like to be able to build out an idea in a week or two and see if it goes anywhere. Making my own metered billing system to go with it would be an enormous project.
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..)
Can i ask why, in 2024, basic internet payment infrastructure isn't a commoditized resource shared across FANG/governments/ISP/banks? Why Does it have to be this way? Why must it be so convoluted for the merchants themselves? Why must it cost so much money just to be able to accept payments? Don't we all love payments? Don't transactions make the world go round? Are we already paying taxes on literally everything? Wouldn't it be in everyone's best interest is to make the simple act of doing business be as simple, frictionless, and barrierless as possible?
What is it exactly that you want Amazon, the US government, Verizon, and JPMorgan doing together that isn't done better by Stripe and its competitors right now?
For a discussion around payments this seems very similar to the "internet is a utility" discussion from decades past with a weird anti-capitalist / "a private company doing this is bad" vibes.
Selling to developers is where i know it will struggle... Developers are cheap ass and would rather build it themselves at 10x the opportunity cost. And the moment it attempts to monetise itself in some form, there'll be a massive "betrayal" exodus a la Redis.
Usage based billing is tough. I took a long hard look at lago and ultimately it wasn't for me (B2C API based business). I couldn't do without the customer portal which is a premium feature, and premium was at least $1,500 USD/month. My revenue couldn't justify this. To Lago's credit, they are purposefully staying away from percentage pricing. So they have to charge a lot on the base price. Stripe Billing charges a percentage and guess what, with a growing business it's only a matter of time before your Stripe bill tops that $1.5k.
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.
I do something similar with stripe. I add two items to the subscription. A base unit that charges a fixed price up front and monthly thereafter. And usage based second item that bills based on usage minus the pre charged items. Usage based fires for the first time on their second charge.
If the user cancels their subscription, I run it through the next payment period for their usage based billing period and then cancel it.
What's a fair price for a budget-friendly hosted version? Lower upfront cost, or maybe a revenue share? We've aimed at enterprise deals for the paid edition, keeping the open-source version widely accessible. Keen to hear your thoughts on adjusting our pricing.
I do something similar with stripe. I add two items to the subscription. A base unit that charges a fixed price up front and monthly thereafter. And usage based second item that bills based on usage minus the pre charged items.
Typical mind fallacy. I personally love paying for things that save me time, and I'm also a developer.
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.
Nah, I'm developer and also I don't like paying for things.
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.
"Typical mind fallacy" = the (subsconscious) assumption that everyone thinks the same way. All I'm saying is that different people have different thresholds for when they buy stuff, even among developers; the best evidence is exactly those commenters you mention who are more willing to spend than you are. (And that's fine!)
For payments, not for billing, right? I'd be very surprised otherwise, considering how Stripe's offer for billing is quite inflexible and (at least 6 months ago) offering experimental features.
Stripe is only used for edge cases in Amazon's payment flow, and Amazon tracks how much of its payment flow and what the cost differential between them processing with their direct relationships would be versus Stripe's markup.
Basically, here are the worst of the worst of Amazon's transactions, please take this risk onto Stripe's platform, then we will cut cost with full knowledge of exactly how much we will save by spending developer resources to cut out Stripe for this particular card type in this particular country.
I would not call this a healthy relationship, but rather stripe taking the marginal additional volume that Amazon brings to their platform to net slightly more money and get slightly more data points on weird payment methods.
But Amazon uses a custom homegrown usage based billing, not relying on Stripe Billing. This is why Lago exists, to offer a flexible usage-based billing architecture for companies offering usage based or hybrid billing without having to build everything on their own.
I am not a cheap-ass developer. I believe that thinking economically is a fundamental facet of engineering, and if you are not thinking economically, you may be doing something, but it’s not engineering. Like the sibling commenter, I am delighted to pay for something that brings value and saves time. Not like I ever considered building my own billing system, anyway…
I don't know anything about funding but most of the funding came in the before times, when we had a zero interest rate policy, right? In post zirp, would even Y Combinator darling Dropbox or Airbnb be able to secure funding (without a solid plan)?
We raised the biggest chunk of the money in 2023, which was far from being « zero interest rate », and « founder friendly », or even « fintech friendly ».
What is true is we raised the initial $3M in 2021, out of YC, on the back of our initial product that was not open source.
Maybe I’m old and my feeling for what open-source means haven’t adapted to the changing reality, but whenever I see “open-source” and “$22 in funding” in one sentence I immediately think “open-source my ass”.
Is there a guide somewhere about how someone’s supposed to create open source software without monetizing it? Or is it just the VC money that makes it not real open source?
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.
While there's lots of different models of open source, what I've seen most often is people setting it up first then selling themselves as gurus and support for major users with money. Often they live low overhead lives - not competitive with SF salaries or startup world. VC money doesn't generally fit this model. While I'm sure there's some, the vast majority of open-source software relied on to run most of the modern world is not VC funded.
(Lago co-founder here)
We shared a few thoughts about « why oss does not win by being cheaper », we are trying o find the balance between oss, quality, sustainability, indeed.
I agree with you, but at the same time what's the alternative? Build it anyway on free time, beg for scraps in donations, and have $corporate sell it as a service while giving nothing back?
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.
Correct me if I’m wrong but isn’t this how suse, red hat, databricks etc work? They offer useful open source tools and make money to sustain development by offering service around those tools.
I could be totally wrong but that is my understanding of some of these projects.
It means "open source until their VCs ramp up the pressure to monetize and they switch to a more restrictive license, screwing over all existing contributors and the rest of the community."
"open source my ass" :)) I don't want to argue with the ass/the gut, but perhaps I can offer an explanation as to why it might feel this way.
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.
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.
Right Lago could be used as replacement to Stripe Billing. And one attractive feature is that it decouples your tech stack from Stripe (could use another payment processor and still handle the subscription lifecycle the same way). This is going to be more and more interesting to businesses who are getting increasingly wary of Stripe account bans.
Yep, couple it with a third party vaulting solution like Spreedly or VeryGoodSecurity and you can dynamically route any card-on-file to any payment processor with a simple configuration change, including routing higher-risk/newer accounts to less ban-happy processors. Honestly surprised that space hasn't innovated more around this offering.
What are you talking about Stripe is great and really well made. I just built on it and was able to do whatever I wanted. Lago looks like just one more platform I'd have to keep track of for no reason.
That when you say "Lago looks like just one more platform I'd have to keep track of for no reason", it clearly means it's not for you, but there might be other users who get benefit from it.
Actually, PCI Compliance is largely a solved problem. Use something like https://verygoodsecurity.com and wrap the proxy around Lago and your self hosting will qualify you for the easiest PCI compliance tier.
(Disclosure: I founded Very Good Security & was the CEO for 8 years).
Blockchain isn't a ledger for legal tender transactions. It's a ledger for tokens, which then have to be converted into an actual currency whose store of value isn't reliant on some Coinbase ticker.
Yep. Nothing here seems to contradict that, unless you have found some magical cryptocurrency that has stable value, is easy enough for my mum to use, doesn't have the security properties of stuffing cash in a mattress (and posting a sign outside your house saying "cash here!"), is properly regulated, allows chargebacks, has fraud protections, etc. etc.
And we built blockchain apps that let anyone release their own at https://intercoin.org
All those other properties you mentioned are not essential to being used as a medium of exchange. People can make their own conflict resolution procedures without involving the daddy government. Your idea of “security properties” is that a bank holds your money, well around the world people get their assets frozen by these banks.
I'm a fullstack JavaScript developer. I'm not too fluent in Rust and Ruby. I would be more efficient poking and hacking a nodeJS codebase. If I treat the whole codebase as a black box there is no advantage for me in using an open source project.
No, but an API is a leaky abstraction. you'll notice slowness, you'll encounter bugs, you'll see shortcomings in the data model used. All of those flow from the choice of language used on the backend. I'm not claiming that any one language is better than another, just that the leaky abstraction means the choice of language will have user-facing consequences.
Completely agree, bad track record and/or explained by help from the EU. Not saying that EU promotions are bad but that there are not enough hungry entrepreneurs in Europe which is easy to explain by the great life standard there. This is the paradox.
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.
> 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.
Anyone have an actual Stripe Payments alternative? I'm stuck on PayPal since Stripe doesn't want to work with us, only with our closed source competition.
We are starting with billing indeed, with a long term vision of becoming the « open revenue hub » (laid out the high level steps here: https://www.getlago.com/blog/lago-raises-22-millions), meaning we want to offer an open alternative to everything RevOps. Instead of choosing to be in a closed source ecosystem like Stripe’s (they have 21 products and most founders don’t realise they are using 3-6 of them, not only « Stripe payments », each of them usually taking a cut on revenue), you could build a customised stack, in a « best of breed » approach, and add the long tail of tools/use cases/home-grown system if you’d like.
We're diving first into creating an alternative to one of Stripe's key services which is billing. We especially building billing on areas where Stripe struggles, like mixed or usage-based billing models.
Can you please explain, why the ruby engineer vacancy is remote only within certain countries - FR, PT, GB, NL, ET, and IT? Why if I live in Latvia or Poland, or Sweden, I can't work with you? I don't want to call you out, but it's just interesting to understand why it's like that and specifically, why we can't try to make the geography more diverse, at least within EU?
Not from Lago, but from my own experience I'd guess it's due to the requirements to set up payroll in different countries. If you hire someone, even as a remote worker, in a particular country, you need a payroll processor to make sure the employee is paid with the correct tax deductions, pay those taxes to the local government, and so on. You also need to make sure that you comply with local labour laws. Doing all of that is far from trivial, so there's a high cost to taking on your first employee in any given country.
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.
Also worth noting that while there are "Employer of Record" and "Professional Employer Organisation" businesses who essentially have branches with payroll etc all set up in a bunch of countries, and can hire people there and act as the nominal employer while the employee actually works for another company, but at least the last time I looked they were very expensive -- at around thousands of $/€/£ per employee per month.
I was working for a company in France, while based in Latvia, and we worked according to B2B contract and I was just invoicing them and paid all my taxes. No problem.
True, that can be a useful solution. But you have to be careful; when I was running a UK-based company we had to get lawyers to carefully draft the contract so that it fulfilled the requirements to be truly B2B and not be something that would be deemed employment. I would expect the rules around that kind of thing to be even tougher in France, if anything.
Because it isn't worth it for a company to set up a new registered entity, find a payroll processor and deal with a whole set of federal/state/local employment laws and tax laws just for a single employee.
Totally agree, thanks for the feedback.
We are working on extending the geos to EU+UK. We have been a lean team so far so we had to « keep it simple to focus on the product and the community » but we have just hired someone fantastic on the Talent & People side, who will be able to improve this.
Meanwhile feel free to email talent@getlago.com for any Qs!
ELI5: what is the value proposition for Lago? That is open-source?
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.
We're diving into creating an alternative to one of Stripe's key services which is billing. Especially focusing on areas where Stripe struggles, like mixed or usage-based billing models. We do offer a great UI/UX ;)
Did you guys implement versioning and grandfathering yet? Iterating on pricing and packaging without overwriting the whole config and f-ing up existing subscriptions is important.
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$
Lago founder here, I can testify we have never bribed a journalist.
I had a call with Ingrid from TechCrunch on Zoom, it was my first time (and unique time so far) meeting her, so I did not even got to buy her coffee.
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.