How we think about our own pricing

Lago was born to enable any company to build a great pricing stack, starting with billing. However, we haven’t communicated about our own pricing yet. So let’s dive in!

This is still an open topic for us but out of transparency, here’s an overview of our thought process and its guiding principles.

‍

What we don’t want to do

Reproduce a “rent-seeker” pricing by taking a cut on your revenue

We’ve been in the buyer’s shoes, and we resented leaving a percentage of our hard-earned revenue to a billing software company. This pricing might make sense for payment providers, as they bear a risk proportional to the amount transacted, but we don’t think it makes sense for billing.

It seems like existing billing solutions adopted this type of pricing, just “because they could” (see the Hacker News reactions on Stripe Billing’s pricing for instance).

Make our users go through an opaque sales process

We’ve also been there, having to talk to an SDR or an AE, receiving a quote, asking your network how much they paid for the same service, negotiating the price… It’s tiring.

When the users’ needs are completely unprecedented and the quote is fully customized, as it can be the case with complex enterprise deals, it’s understandable. Otherwise, it doesn’t seem to be a good use of anybody’s time.

‍

What we want to achieve

A pricing in line with the impact and value we help create.

A pricing that is as transparent as possible: anyone should be able to estimate how much it would cost by visiting our website.

A pricing that allows us to have a long-term impact. We’re on a mission to build the billing standard for the next generation of software companies, often referred to as “product-led growth companies”. This means asking our users to pay when something costs us money, as we need to generate enough revenue to keep investing in our product, and therefore our community, for the next ten years.

‍

Hypotheses on monetization

Lago Cloud: our fully hosted product

We received many requests for a fully hosted version of Lago, and this version is currently available in beta - email us at hello@getlago.com if you’re interested. Lago Cloud is something we could potentially monetize. We’re iterating on potential pricing models that would be both fair to our users and sustainable.

Catering to later stage companies with our self-hosted product

Surprisingly, we also had strong inbound leads from mature companies, interested in the self-hosted version of Lago, combined with a custom setup and onboarding. These companies have built home-made systems that they no longer want to maintain, and have particular needs that none of the closed-source SaaS can address.

Working with these companies could generate a source of revenue for Lago and be an opportunity to deepen our knowledge to improve our core product. That being said, we’re fully aware that enterprise deals are time-consuming, and could take resources away from our initial mission. So we’re considering this possibility with a grain of salt.

Embedding Lago for channel marketing

We’ve also been contacted by platforms willing to embed some of Lago’s features into their own product. For instance, a verticalized SaaS that provides billing features to other businesses (i.e. their users) so that they can bill their own customers.

According to our license, these platforms would need to share the source code they used to embed Lago. Not all platforms are willing to do this, so a workaround could be to let them buy a license from us.

‍

What our pricing structure could look like

Making our users pay based on how much work and resources we mobilize for them could lead to using several potential “billable metrics”, including:

The number of customers that are billed: simple to understand but not really consistent with the time and effort we put into serving them.

The number of events we need to ingest (the number of events increases with the complexity of your pricing and number of customers). We could then define a decreasing logarithmic rate according to the volume of events (in a very simplified way, something like "if the volume goes up 10x, the incremental price decreases 5x"). With this pricing, there would be a better correlation between the price and our costs but it would be less predictable for our customers.

For instance, Firebase’s pricing would require us to measure usage on multiple dimensions, including at a /min/day granularity level, and therefore to ingest a much higher volume of events than its open-source counterpart Supabase, that opted for a “per project” pricing (see below).

‍

‍

‍

We will iterate to get it right

Pricing is obviously a sensitive matter, as it impacts our mission and our sustainability. We won’t get it perfect from day 1, and might need to iterate through different phases: a fixed subscription fee might be a reasonable starting point for instance.

If you want to go further into this topic, we highly recommend James Hawkin’s post about Posthog’s pricing lessons, which are summarized in this thread. Another insightful read is “How to pay your rent with your open source project” by Marko Saric, who co-founded Plausible, the open-source Google Analytics alternative.

At the moment, we’re focusing on building trust and iterating on our product to make something people truly want. We also see this phase as an opportunity to talk to our community and try to understand what a fair pricing could be.

As you can see, monetization is still an open question for us, but our guiding principles are very clear.