HN Explorer

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

442 points by Rafsark ↗ HN
Hi HN, we’re the cofounders of Lago: an open-source alternative to Stripe Billing, Chargebee, and Recurly. That is, we make software that helps businesses calculate how much their own customers should pay them—based on their subscription, consumption, discounts, taxes, credit notes, or negotiated terms—and then invoice them.

Our website is at https://www.getlago.com and our Github is here: https://github.com/getlago/lago.

We’re focused on composability (use only the parts you need), metering (measuring how much of a software service end users use, so that the service can charge them based on that), code transparency (we’re open source, so no black box - you can have a full understanding of how we built our API) auditable code, no lock-in into anyone’s ecosystem, and fair pricing (we don’t take a cut of your revenue).

We’ve been in Fintech for more than 7 years, and were the earliest employees at Qonto.com (SMB Neobank in EU), where we built and scaled the billing system and led the revenue team that took the company from pre-launch to $100M+ of ARR.

Back in the early days at Qonto, our pricing was very simple, a single “all-included” subscription. We budgeted 3 months of a single back-end to “get it done, once and for all”. As we shipped new features (add-ons, new tiers, usage-based etc), improved the packaging, changed our reporting structure as we matured (or instance, we changed the billing cycles from anniversary dates to calendar dates which looked trivial until we had to migrate 100K+ companies), launched new countries (new prices, new taxes implications new reporting!), we iterated on pricing dozens of times.

We consistently underestimated the engineering nightmare billing would create, and learned the hard way about side effects: delayed launches at best, billing errors at worst, resulting in churning users. We wrote an article about this that had a large HN thread last year (https://news.ycombinator.com/item?id=31424450).

We tried to get rid of our home-grown system many times but never found an alternative that was flexible enough. As a result, there were only two options: either stop iterating on pricing and leave revenue on the table, or grow a billing engineering team. We chose the second, but it was expensive. Finding pricing or monetization experts living in spreadsheets is easy, but finding technical professionals to build and maintain a billing system is a real bottleneck. Few engineers or product managers have experience in billing, and it’s rarely a career path they look forward to.

At some point, we realized we’d stopped being able to do pricing strategy based on what was best for the company and found ourselves driven by what was easiest to implement—not because we wanted to, but because it was all too complicated. We asked around and realized a lot of companies were in a similar situation. There are a lot of clunky internal billing systems out there! We spent a lot of time analyzing why no one had solved this problem, as we thought companies like Stripe or Chargebee had partially addressed it. We came to the conclusion that a proper solution needed to be open source.

A lot of teams continue to build their billing system themselves because they have unique edge cases that closed-source solutions can’t address. They are part of the “long tail”, which a closed-source SaaS has no incentive to invest in solving. That’s how we arrived at the idea of open sourcing “core billing” foundations that other people could use and build on. We don’t solve 100% of use cases either, but what we don’t solve, others can build, without having to reinvent an entire system. We think of Lago’s features like “Legos” you can pick to build your own system, rather than a “one size fits all” billing platfor...

143 comments

[ 3.1 ms ] story [ 233 ms ] thread
rabidonrails
Congrats on the launch, definitely an interesting product and really interesting space. But...didn't you guys launch a while ago? Is there something specific you're launching now?

>> The tech stack we use to build Lago (YC S21), the open source billing API (https://news.ycombinator.com/item?id=32438355)

>> Lago: The Open Source Stripe Billing Alternative (https://news.ycombinator.com/item?id=32438355)

>>Lago: The Open Source Stripe Billing Alternative(https://news.ycombinator.com/item?id=31638797)

>>Show HN: 6 Steps to build a usage-based billing system with Lago (YC S21)(https://news.ycombinator.com/item?id=32765162)

>> Show HN: Lago: Open-source metering and usage-based billing (https://news.ycombinator.com/item?id=33505229)

Rafsark
Hi Rabidonrails, We have decided to launch an official HN campaign for the beta release of Lago (https://www.getlago.com/beta). This Beta covers the full range of billing features (credit notes, bill on customers' timezones, invoice grace periods...) and we believe that our product is now suitable for a wider range of users and use cases.

Our previous articles focused on billing-related content. They discussed various aspects of billing, such as Stripe fees, alpha launch, and various features.

arnon
Congrats Anh-Tho and Raffi! I think this will be big
tpayet
Congrats on the launch!
AnhTho_FR
Thanks Arnon! I often keep sharing your blog post on entitlements: https://arnon.dk/why-you-should-separate-your-billing-from-e... !
ezekg
This is a great answer to a question I get asked a lot. Thanks for sharing!
AnhTho_FR
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
ezekg
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...

AnhTho_FR
Sure! My email: anhtho[at]getlago.com
candiddevmike
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.
Rafsark
In my opinion, the future of billing lies in a hybrid approach. Former subscription- or per-seat-based models were too restrictive. Subscriptions with capped features prevented users from upselling and generating more revenue. The gap between the base subscription and upsell was often too large.

I agree that usage-based billing can be difficult to predict revenue from. We don't think companies will switch entirely to this model. However, the hybrid model can be beneficial for both customers and vendors. Companies can charge a base platform fee and then charge for overage instead of blocking it. This could increase revenue for companies that currently use subscription-based billing.

jrockway
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 confusing. And when customers are confused, they simply chargeback the credit card charge. AWS can make it work, but I'm not sure if everyone else can. Will be interesting to see.

swyx
> And when customers are confused, they simply chargeback the credit card charge.

this is not good faith B2B behavior. i'd be surprised if 1% of B2B usage based billing customers behave like this.

AnhTho_FR
I think B2B users would rather dispute the invoice with their account manager and might get a discount.
jrockway
I agree that it's not good faith, but speaking from the position of someone who has offered self-service signup... that's what customers did. They'd create an account, start using the service, ignore emails from their account manager, and then dispute the bill when we charged their card. This is rare, of course, but it is something you have to expect when you give someone free reign to spend money and then bill them at the end of the month.

It's something you have to expect, and kind of gauge how much money the customer has and send them lots of email as they approach a limit, and make it very clear in the UI that money is being spent that they will soon have to pay. Even then, who knows what people will do. It's bad faith on their part; you, the service provider, are the ones penalized.

kdeldycke
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 in place to prevent abuse and limit fraud. As we had similar hard-coded heuristics for the same reasons.

paulgb
Small bills are funny. I'm surprised if the interchange fees don't net out negative for the biller.

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.

kdeldycke
> surprised if the interchange fees don't net out negative for the biller

That's worth investigating!

Now in a fictional, adversarial way, you can think of a bot exploiting this discrepancy to bankrupt a competitor: create dozens of fake accounts, consume just shy of $0.01 of resources, and have the platform pays 30x more in payment fees (public Stripe price is 30¢/transaction).

To incur a net loss of $1,000,000, you’ll have to find an antagonist ready to create 3,448,276 accounts (1_000_000 / (0.30 - 0.01)), each with their own identity and mean of payment, for a total of $34,482.76.

Fortunately this is highly impractical and will be caught real fast by your internal anti-abuse systems (you have those in place right?).

karambahh
Is it that impratical?

Small players would be impacted by a 100k$ net loss...and you could even spread it out over several months to be less likely to be caught by anti-abuse systems...

jrockway
I was in this position and Stripe let me carry over the line items until eventually an invoice was billable, if I recall correctly. Though I might have just manually waived these charges as a courtesy.
epberry
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.
superzamp
Side story, and that might not be true as of today, but Datadog was a nightmare billing-wise for me. Probably precisely because they didn't use a tool like the one launched in this post. Anything ranging from seeing your live usage to getting a rough idea of what your bill at the end of the month would be was impossible, not to mention the absence of any kind of alert even after reaching $30x our previous month usage. Usage based is fantastic when done properly, but can quickly turn to a nightmare for the user on half-assed systems.
AnhTho_FR
I heard they only fully automated it post IPO, and have a full team of senior engineers + PM on this topic now!
gneray
Love to see this. Congrats!
nwatson
In years 2000/2001, as the dot-com implosion was happening, I worked for a company where we did patent disclosures (I spent a long time talking to a patent lawyer) discussing in depth ideas for billing systems, including a vendor / distributor / consumer model (where any entity could be any one or a combination of those w.r.t. a product), data structures, data-collection frameworks, billing "metrics", passthrough-billing-with-a-cut, differential pricing, resale of combined products, etc. These were turned into patent applications that perhaps merited becoming full-blown patents, or perhaps not. Given the recent rash of companies doing this (e.g., https://www.monetize360.com/), I think they were patentable ideas 20+ years ago. The referenced applications should give some prior art coverage for many patent issues one might run into.

Of course, the vendor/distributor/consumer model can become vendor-many-clients through simplication, same ideas hold.

As it turned out, the company was lucky to have some data-storage-discovery-and-inventory software built as part of the bigger eventual vision that attracted a buyer. It was not the time to work on ambitious greenfield stuff, I guess. The patents were not relevant to the acquirer, and they lapsed at some point.

https://patents.google.com/patent/US20030083998

https://patents.google.com/patent/US20030084000

https://patents.google.com/patent/US20030083892

https://patents.google.com/patent/US20030083995

https://patents.google.com/patent/US20030083994

https://patents.google.com/patent/US20030084145

https://patents.google.com/patent/US20030083999

https://patents.google.com/patent/US20030084060

https://patents.google.com/patent/US20030084343

https://patents.google.com/patent/US20030084341

[edit: 2000 -> 2000/2001 ... "any patent issues" --> "many patent issues" ... a few other in the inventory of ideas ... simplification of model to vendor-many-clients ... fixed one link]

vnoochet
I have been keeping track of Lago's team for a while now, and I am continually impressed by their achievements and the speed at which they are delivering. Congratulations on the launch!
Mino_Skeu
We use Stripe, any difference ?
Rafsark
Yes, there are many differences between Stripe and Lago. Here are some of the most common:

Lago is completely agnostic of payment providers, meaning you can use any payment service provider (PSP) with it, whereas Stripe requires the use of its entire stack.

Lago is event-based, making it easy to ingest a high volume of usage-based components. This eliminates the need for users to manually bill their own usage-based billing aggregation on top of Stripe.

Lago is open-source, so there is no revenue taken as a cut. For its fully cloud-hosted version, Lago prices a platform fee and tiers on usage-based events, making it more scalable for high-volume companies. Additionally, its open architecture allows for full customization to fit your needs.

rapnie
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://www.getlago.com/blog/open-source-licensing-and-why-l...

https://plausible.io

Rafsark
Thanks! We're big fans of Plausible and appreciate you mentioning them in your comment. We wanted to be transparent about why we chose this license. Our goal is to create a sustainable open source product, both in terms of quality and vision.
rvz
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.
harrylucas
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?
louis-lau
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 it this way, and AGPL is only really meant to restrict businesses that want to fork it and start a proprietary billing service.

AnhTho_FR
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.
AnhTho_FR
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!
e12e
> OR open source your code

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).

leonidasv
If you don't change the source code of Lago, then you don't. Having your app call it via REST, for example, is fine.
hummus_bae
Exactly. We’ve seen people go from “I don’t want to do this because I don’t want to force my users” to “Guys let’s do it AGPL it’s the way to go”.

Restricting your usage tracking to your users is fine until you start shouting to them directly on their phones.

evv
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!)

sokoloff
I think the difference in cases is that in case 1 above, I read it as your company's employees [or technical systems] are using the software for some internal billing purpose and no outsiders are using the system, but are rather merely receiving a bill which was calculated using that system.
canadiantim
Congrats on the launch! I fully intend on using Lago for my SaaS.

I wonder, would it ever be possible to use the structure provided by lago to also set up a marketplace where user can buy/sell from eachother?

Rafsark
Thanks, we're excited to have you on board! We've had some requests about billing for marketplaces. Currently, Lago is designed to bill subscriptions with embedded fixed fees and usage-based fees, resulting in a consolidated "end of period" invoice. Marketplaces, however, require immediate invoicing with a different logic. We have a product vision dedicated to SaaS for now, but this could be a use-case to tackle in the future.
canadiantim
That's great to hear marketplaces are a possibility in the future, even if it's a remote possibility right now. I understand you want to focus and hone in on your current product vision, but glad you are open to serving marketplaces too. Thanks for the great product!
ferdi05
Congrats on the launch! And thanks for helping the open-source ecosystem to thrive. I'm always happy to see open-source companies challenging the status quo. Open Source is very often the most reliable choice, and you contribute to spreading the word.
Rafsark
Thanks for the kind words. At Lago, we want to break the notion that billing is always a "buy or build" option. Billing can be so different between companies that it may require a custom setup, infrastructure, and model. Furthermore, the "buy" options available are often not scalable enough for large companies.

With our open source version of Lago, we offer: - Fair pricing: scale your billing as your company grows - Composability: build the pricing/billing you have in mind, without the limitations of vendors - Participative approach: contribute to the entire billing engine so other companies can benefit from it.

haolez
After clicking on your repo link, for a moment I was taken aback by the repo being 100% written in shell script. :)

But then I've noticed that you use git submodules for the frontend and backend. It's actually a Rails application from what I can tell.

jdenquin
Hey @haolez, yes the main repo contains all the docker configurations and 2 subsmodules, so you just have to clone this one and have Lago up in 2 minutes if you want to try it out! Our api uses Ruby On Rails and our front end is build with React!
asselinpaul
Congrats on the launch!

Any plans to tackle Stripe Connect like functionality (platform / marketplace payments)?

Rafsark
We have a growing number of requests for this use-case, but we try to focus on billing right now. However, I can promote Formance (https://www.formance.com/) here that can help on this vertical. They are YC folks, and tackle the use-case of collecting fees and splitting payments. And it's also open source! Hope this helps
AnhTho_FR
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
asselinpaul
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 :)
AnhTho_FR
We might have ideas for you! Lago won't cover all these use cases today, but we're working with other players that can provide an alternative stack. If you're interested, would you mind emailing us? Founders[at]getlago.com Thanks!
simplify
How is usage based billing taken from the user's point of view? Isn't there a sense it disincentivizes a paying customer from using your product?
Rafsark
In our opinion, the future of billing is hybrid. This means customers pay a platform fee (a subscription) but don't face blocks for exceeding their plan's limits. Offering multiple plans with appropriate entitlements related to the feature set is still possible. However, blocking usage instead of billing for overage represents a lost revenue opportunity. Most customers won't upgrade, so we recommend allowing them to pay for overconsumption on top of the base fee.
wongarsu
Usage based billing disincentivizes customers from using your product. Seat based billing disincentivizes customers from giving people access to your product. Feature based prizing makes it harder to try features locked in more expensive plans, and disincentivizes smaller use cases.

Which of those is the smallest negative depends on your product.

rileyphone
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!
nylonstrung
How do you guys differ from Lotus, the other YC open-source usage based billing company?
Rafsark
Hi,

First of all, we launched our open source billing repository months before they did. In fact, they even reached out to us for inspiration. This could be related to the fact that our team has prior experience building billing engines, so we have a better understanding of the space.

From a product perspective, our coverage is more extensive. We provide more advanced coupons, usage-based components and billing use-cases. For example, we offer credit notes and refunds, small examples that are not listed in their API. Our product covers more billing edge-cases and deeper features.

Finally, we have customers in production. Our top user is invoicing 5M customers a month, which might not be the case for them.

To conclude, I would assert that we are more advanced.

Kiro
That's a pretty obnoxious reply, especially considering they are your alumni. Be more humble.
Rafsark
Hi Kiro, I don't consider this an impudent response. We strive to base our answers on facts, from both the team and product perspectives. We tried to detail differences from a product point of view. We respect everyone in this space, including established vendors and newcomers. They all have a positive influence on our product, pushing us to deliver faster with higher quality.
louis-lau
I love your product, but this reply reads snarky and arrogant.
fragmede
If the underlying premise of the message is "mine is better", how would you phrase it without coming off as arrogant?
louis-lau
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 provide more advanced coupons, usage-based components and billing use-cases. For example, we offer credit notes and refunds, small examples that are not listed in their API. Our product covers more billing edge-cases and deeper features.

While we don't know how many customers Lotus has in production, our top user is invoicing 5M customers a month!

Overall, we believe at this point that our product is more advanced. We wish them luck though, the more products in this space the better.

AnhTho_FR
(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!
louis-lau
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! :)
AnhTho_FR
Definitely! Also we posted at 6AM PT time and are really jet lagged, and I think Raffi had not had coffee yet!
codegeek
"Months before they did". That doesn't mean anything. Being first is not always why you are better. Myspace was first. Friendster was first. Alta vista was first. Lycos was first.

Focus on why your product is better or different and not these factors like who was early, who has more experience with billing engines etc because again, experience doesn't translate to success necessarily.

All the best.

mikaeln
I'm a cofounder at Lotus (https://github.com/uselotus/lotus).

First, congrats on the launch Lago. I've been very impressed with your ability to educate devs about the intricacies of billing and you are certainly pushing the entire space forward.

While you offer coupons and credit notes, there are features you don't have that we have prioritized and built, including, usage alerts, plan versioning, gauge metrics, custom sql etc. etc. Point being I think its unfair to say we are a subset of your product.

In addition, we have a 25+ year billing expert on our team who has been CTO of a startup processing $300 million a year.

Lastly, I don't think it's fair to make statements about our customers just because we haven't "announced" them yet.

Happy to chat more with anyone about our differences.

Kiro
You replied to the wrong comment.
i_robi
Congrats on the launch! Do you think it is appropriate for any kind of SaaS company (e.g. Figma, Airtable…), or just for companies like Snowflake?
Rafsark
Thanks! We cover all types of SaaS companies' billing. We often say that if you can track it, we can bill it! We cover subscriptions, hybrid, pay-as-you-go, and per-seat pricing models. We believe that the future of billing is hybrid - a mix of all the above. We've seen many missed revenue opportunities from companies that weren't able to price overage on top of a per-seat or pure subscription pricing (often because it was too hard to build, either internally or with existing vendors)
JeanEdern
How do you compare with other processes and workflows to manage billing? For example: using snowflake + DBT to track billable metrics?
Rafsark
You can still use Snowflake + DBT to track usage. However, this won't cover billing use cases. On top of this, you could need to create invoices, trigger payments, handle coupons, and issue credit notes. Many customers use warehouses to track usage and send usage-based HTTP events to Lago. This is the first step towards a full consumption-based or hybrid billing model. Ensure continued revenue and customer satisfaction by covering the entire billing, pricing, and invoicing workflow (not only aggregating usage)
[deleted]
(comment deleted)
jmacd
Exciting 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, entitlement management, CPQ, feature gating, and everything else required in a modern SaaS company, the PriceOps space can be quite complex for developers.

Congratulations on the launch and best of luck!

Rafsark
Thanks! The space is becoming more and more exciting. Many players will emerge in different verticals, creating a great impact. Companies will be able to price, invoice, and track usage with greater precision.
adeptima
As all-in-Golang user, wish Tier to succeed too!

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...

afeiszli
We decided to use Lago with our SaaS. Billing is super complicated and Lago handles everything we need out of the box. Building this stuff would have been a nightmare. Really cool!
AnhTho_FR
Thanks for your trust, it means a lot to us!
josefbvt
Wow this is finally happening! Big fan of this team and this product! Congrats for this launch, this is the first milestone of an amazing journey reinventing billing for tech companies!
AnhTho_FR
haha we've been working hard to get to this point, thanks!!!