[HN Gopher] Launch HN: Lago (YC S21) - Open-source usage-based b...
___________________________________________________________________
Launch HN: Lago (YC S21) - Open-source usage-based billing
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 platform. Unlike closed
source solutions, we aim at giving full transparency on how Lago
works (auditable code), and enable our users to pick only the parts
of our product that are relevant to their needs (e.g., if they are
already handling subscription management but want to manage prepaid
credits with Lago, they can). You can make your own design
decisions, build anything custom that you need, and collaborate
with other engineers in the community. For instance, one of our
users built a Javascript SDK that is now available to everyone.
Others are developing additional "charge models": for instance we
don't offer the ability to "cap a charge" yet: if you're a fintech
processing transactions, you'd like to bill for instance "2% of the
transaction amount capped at $50", to make your pricing attractive.
We're working with a team who are contributing this to Lago. Other
contributions involve adding native integrations with local payment
processors (in India, Northern Europe, Africa, Middle East),
because they usually cater better to the needs of local players in
these regions: better payment success rates, better conversions at
checkout pages, and usually better prices. We're making Lago as
open as possible to adjacent tools (e.g., payment processors,
quoting software, CRMs, etc.)--both market leaders and niche
solutions in smaller markets. We've built native integrations with
GoCardless and Stripe Payments, but our API is usable with any
payment processor from any region, and some community members are
already doing so. We're also partnering with Osohq.com, open-
source as well, that manages authorization and entitlements
(granting access to a specific feature if a user had subscribed to
a specific plan):
https://doc.getlago.com/docs/integrations/entitlements/oso You can
also use Lago with automation tools like n8n.io to create
workflows, for instance if you notice your end users have an
unusually high consumption of your product, and you want to avoid
"bill shock", you might want to alert them or your customer success
team to take proactive actions:
https://doc.getlago.com/docs/integrations/alerting/n8n#overc...
We're actively working to build an ecosystem around Lago and
address the long tail of edge cases that makes billing and
monetization complex, with the help of the community. How it
works: Lago collects HTTP events sent by a backend application.
These events are automatically aggregated to create "units to be
charged". Each unit can be priced using different pricing models
(tiers, packages, percentages). At the end of each billing period
(month, quarter, year), a worker gathers all the fees into an
invoice (PDF or JSON webhook message). The issued invoice can be
connected to various services (payment providers, accounting tools,
CRMs) and edited with discounts or credit notes to adjust it. Once
the back-end events are sent to Lago, non-technical users can use
our user interface and manage pricing without help from engineers.
This is what our UI looks like: https://youtu.be/dXnoMRetsr4 Lago
is self-hostable and you can download a Docker image here:
https://github.com/getlago/lago. We also have a cloud product that
is being used in production. For now we're still granting access
manually, but we'll make it generally available in the near future.
In terms of pricing: the self-hosted product, which contains the
core billing features, is free. We've tried to make it featureful
enough for a business to just use the free product and build what
they need on top of it. Premium (i.e paid) features currently
include billing on different time zones, credit notes, and will
include Salesforce integration in the future. Beyond that, we're
still working out our approach to pricing and have written some of
our thoughts about it here: https://www.getlago.com/blog/how-we-
think-about-our-own-pric.... The billing / monetization is space
is huge and we're continuing to learn every day, so we would
greatly appreciate and are (nervously) eager for your feedback!
Thanks!
Author : Rafsark
Score : 313 points
Date : 2023-02-13 14:01 UTC (8 hours ago)
| candiddevmike wrote:
| 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 wrote:
| 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 wrote:
| 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.
| epberry wrote:
| 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.
| [deleted]
| stephanieglsr wrote:
| Congrats on the launch!!
| NathanFlurry wrote:
| We just rolled out Lago billing in Rivet yesterday. Lago is very
| well designed and the team is incredibly helpful!
| AnhTho_FR wrote:
| Amazing to read, I was excited to see this 2 days ago, thanks
| for your trust!
| simplify wrote:
| 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?
| wongarsu wrote:
| 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.
| Rafsark wrote:
| 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.
| Aishwarya_g wrote:
| This is such a great product and a must have for new age API
| based products. Congrats on the launch!
| AnhTho_FR wrote:
| Thank you so much!
| JeanEdern wrote:
| How do you compare with other processes and workflows to manage
| billing? For example: using snowflake + DBT to track billable
| metrics?
| Rafsark wrote:
| 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)
| aidanlister wrote:
| 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 really
| tricky part. Revenue recognition, plus simple things like
| correctly tracking upgrades/downgrades vs expansion/contraction
| when someone changes plan mid-month.
|
| Is this something that Lago does now or intends to include? I
| could not see it in the docs.
| AnhTho_FR wrote:
| 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!
| gneray wrote:
| Love to see this. Congrats!
| Mino_Skeu wrote:
| We use Stripe, any difference ?
| Rafsark wrote:
| 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.
| rileyphone wrote:
| 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!
| AnhTho_FR wrote:
| Thanks!!!
| nwatson wrote:
| 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]
| nylonstrung wrote:
| How do you guys differ from Lotus, the other YC open-source usage
| based billing company?
| Rafsark wrote:
| 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 wrote:
| That's a pretty obnoxious reply, especially considering they
| are your alumni. Be more humble.
| Rafsark wrote:
| 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.
| throwaway744678 wrote:
| Don't sweat it, your answer reads fine.
| louis-lau wrote:
| I love your product, but this reply reads snarky and
| arrogant.
| fragmede wrote:
| If the underlying premise of the message is "mine is
| better", how would you phrase it without coming off as
| arrogant?
| louis-lau wrote:
| 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 wrote:
| (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 wrote:
| 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 wrote:
| Definitely! Also we posted at 6AM PT time and are really
| jet lagged, and I think Raffi had not had coffee yet!
| ferdi05 wrote:
| 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 wrote:
| 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.
| xyst wrote:
| great project and thank you for open sourcing! this is something
| I need for a future project and you have already built all or
| most of the features I need for the billing aspect.
|
| I'll explore the product more on my own and will try to
| contribute back where possible
| AnhTho_FR wrote:
| Awesome! Yes, feel free to contact us at
| founders[at]getlago.com if you need anything!
| rabidonrails wrote:
| 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 wrote:
| 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.
| dang wrote:
| Each YC funded startup gets one "Launch HN" post (see
| https://news.ycombinator.com/newsfaq.html,
| https://news.ycombinator.com/launches,
| https://news.ycombinator.com/yli.html). It's fine if they've
| already launched. If they're already well-known to the
| community it might be different, but that's rare. In this case,
| for example, none of the posts you linked to got much
| attention.
| super256 wrote:
| Might be interesting for some:
| https://youtube.com/watch?v=3xU050kMbHM&feature=shares
|
| YC video about launching and launching again.
| AnhTho_FR wrote:
| Yes, it's definitely very YC to work on multiple launches.
| Intercom wasn't YC backed but they actually launched a dozen
| times!
| shrisukhani wrote:
| Lago is awesome. We'll likely use Lago at my startup (metlo) when
| we implement full self-serve usage-based billing.
| afeiszli wrote:
| 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 wrote:
| Thanks for your trust, it means a lot to us!
| i_robi wrote:
| 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 wrote:
| 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)
| neoecos wrote:
| 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.
| AnhTho_FR wrote:
| Honored to work with you!
| josefbvt wrote:
| 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 wrote:
| haha we've been working hard to get to this point, thanks!!!
| JeanEdern wrote:
| Congrats!!!
| rapnie wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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?
| AnhTho_FR wrote:
| 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!
| leonidasv wrote:
| 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.
| louis-lau wrote:
| 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 wrote:
| 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.
| evv wrote:
| 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 wrote:
| 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.
| hummus_bae wrote:
| 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.
| foxbee wrote:
| This looks great. Your website is clean and informative - great
| work. Stripe is awesome but a self-hosted option fits our culture
| and philosophy a lot better. Will give it a blast when i get a
| chance.
| Rafsark wrote:
| We put a lot of effort into the website and its messaging. This
| helps users understand how billing works, as the complexity of
| the features behind it can be difficult to grasp. To help, we
| often explain the problem and the solution. Glad you like it!
| Scene_Cast2 wrote:
| Interesting. Would you know how this compares to turnstile [0]?
| (I only know about them because I saw their hiring page on HN a
| week or two ago, and was intrigued.)
|
| [0] https://tryturnstile.com/
| Rafsark wrote:
| Don't have much information about them, but it seems that we
| are API first while they are focusing on no-code (from what I
| understand from their homepage). The common path would be that
| we both have a UI to let non-tech users handle billing actions
| without engineers.
| addandsubtract wrote:
| 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 something Lago supports, or at least
| something that I can accomplish with my business logic (ie.
| prefixing plans with A, B, etc) - or completely out of scope?
| Rafsark wrote:
| 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
| vnoochet wrote:
| 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!
| neximo64 wrote:
| It is quite sneaky on the get started page. You are pushed into
| the cloud option, since the self hosted text is the same color as
| the background and you can't see it.
| Rafsark wrote:
| You are totally right, that's a good catch. Just changed the
| text color to white! Thanks a lot for your feedback
| arnon wrote:
| Congrats Anh-Tho and Raffi! I think this will be big
| AnhTho_FR wrote:
| Thanks Arnon! I often keep sharing your blog post on
| entitlements: https://arnon.dk/why-you-should-separate-your-
| billing-from-e... !
| ezekg wrote:
| This is a great answer to a question I get asked a lot.
| Thanks for sharing!
| AnhTho_FR wrote:
| 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 wrote:
| 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 wrote:
| Sure! My email: anhtho[at]getlago.com
| tpayet wrote:
| Congrats on the launch!
| haolez wrote:
| 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 wrote:
| 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!
| PierreTouzeau wrote:
| Nice!! congrats on the launch!
| canadiantim wrote:
| 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 wrote:
| 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 wrote:
| 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!
| jmacd wrote:
| 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 wrote:
| 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.
| uto31 wrote:
| [dead]
| asselinpaul wrote:
| Congrats on the launch!
|
| Any plans to tackle Stripe Connect like functionality (platform /
| marketplace payments)?
| AnhTho_FR wrote:
| 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 wrote:
| 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 wrote:
| 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!
| Rafsark wrote:
| 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
| telecuda wrote:
| Congrats! We built a usage-based telephony (voice & sms) billing
| system for our customers and appreciate the pain. Not to take
| anything away from your launch, but founders / product managers
| should carefully consider if usage-billing (even with a tool like
| Lago) is best for your business and customers.
|
| We started as usage-based then learned a few years in (once we
| understood customer usage trends - key) that customers would
| gladly pay ~20% MORE per year for unlimited access because the
| customer wanted a predictable bill. We essentially rode the same
| trend of pay-as-you-go mobile to unlimited plans.
|
| Later in our history we found investors (and our accountants)
| liked the predictability as well. It's easier to show "up and to
| the right" when not dealing with a few large customers varying
| down in usage in one quarter (even if the business was on the
| upswing).
|
| One-size doesn't fit all -- usage billing has its place for sure
| -- just carefully weigh your model as it's a huge lift to flip it
| midstream.
| AnhTho_FR wrote:
| We 100% agree with you. Actually the first tagline of Lago was
| "billing for product led SaaS", the wording was a bit
| confusing, but our thoughts were:
|
| (i) "pure usage based pricing" models (like Snowflake's) aren't
| going to be the main standard for SaaS, for the reasons you
| mentioned, the main being predictability (for the merchant and
| the end-user). Cash collection is also a big pain: if you
| collect cash after the consumption, the dispute rate can be
| high. (ii) However pricings will increasingly incorporate
| "usage dimensions" (monthly active rows, number of emails, GB
| used, etc) and this trend is spreading very fast (3 out of 5
| SaaS according to the latest OpenView report). It can take many
| forms: Annual subscriptions including a monthly base usage
| and/or prepaid credits based on consumption, and/or an amount
| of payments processed, etc This is what we lived at Qonto.com
| and solved for, for 4 years, and you woudn't think of it at a
| "usage based player" though, we rather had "usage
| subscriptions" : https://qonto.com/fr/pricing All the possible
| combinations make the billing very hard to maintain and iterate
| on, and this is why we built Lago. All this to say, we 100%
| agree with you that not all companies should choose a "full
| usage based pricing" but find a balance or at least iterate
| between "subscriptions/fixed amount" and "usage based".
| perlgeek wrote:
| I work at an IT service provider that also offers some cloud
| products.
|
| Customers start out by wanting all the flexibility (for their
| devs, usually) to spin up their owner servers, and want used-
| based billing. It would be a waste to pay more, no?
|
| Then their own book keeping department yells at them, because
| they use SAP, and every bill that differs from the contract or
| the previous month is sheer hell and requires 5 levels of
| approval / justification / whatever.
|
| So the next iteration is that they buy a fixed contingent of
| "cloud points" per month so that the invoice remains constant,
| and there's reporting and/or a firm (but often unwritten)
| promise from the account manager that they'll notify the
| customer if/when they ever run the risk of exceeding their
| contingent.
|
| In really big / inflexible companies, it really seems to be
| easier for the purchasing managers to justify higher but
| constant prices than variable prices. The inefficiency boggles
| the mind.
| AnhTho_FR wrote:
| This is really what we've observed indeed! The companies
| catering to later stage companies prefer to offer prepaid
| credits to their end users, or annual plans paid in advance
| that includes some prepaid usage than a full, non predictable
| usage based pricing. I think in that case it's preferable for
| the end user, but also for the company, as their finance team
| can have more visibility on the upcoming revenue streams.
| nojs wrote:
| I'm interested how you handle suppliers that have usage-based
| pricing (which I imagine are the norm in the telephony space)
| if you can't pass this on to the customer. Do you offer your
| customers an unlimited plan, price it high and just hope they
| don't use so much that you go backwards?
| AnhTho_FR wrote:
| I guess it was a question for telecuda, but I've worked 3y
| for telecommunications groups fresh out of business school
| and what you describe is pretty much the approach. Sometimes
| if it's a big group, they might have historical data and can
| make "informed guesses" but at the end of the day, this is
| it. And if the unlimited offer isn't viable (business wise),
| they just sunset it, and usually "grandfather" the offer.
| truetraveller wrote:
| Providing "unlimited" is a major competitive advantage. The
| hard part is predicting the average cost per customer. One can
| use historical metrics to help. The final price would then be
| set according to the average cost, taking into account profit +
| padding for outliers.
| TheJoeMan wrote:
| > It's easier to show "up and to the right"
|
| I think it's funny how MBA's at the end of the day base their
| decisions on glancing at a chart. So now, the engineers are
| catching on to optimizing for that pretty chart.
|
| I made a mistake by spitballing sales figures for a product and
| someone incorporated it into an ROI calc that was being judged
| to the decimal place.
| rubenfiszel wrote:
| Congrats on the launch, as a growing and open-source startup
| ourselves, we are eager to switch to Lago as soon as our stripe
| fees are gonna become a PITA which I expect to be in the near-
| future. The product looks amazing and the API seems super well-
| designed!
___________________________________________________________________
(page generated 2023-02-13 23:00 UTC)