Engineers need open source to end their billing nightmares

A couple of weeks ago, we published an article on Hacker News called “Why billing systems are a nightmare for engineers”. It was a genuine and aboveboard feedback on experiences we had while building the billing system of Qonto, a $5 billion fintech unicorn.

We were surprised by how strongly it resonated:

• Top ranking / top page on HackerNews for 36 consecutive hours;
• Close to 800 points reached; and
• More than 330 comments confirming how hard billing is.

This wave of reactions  gave us an even stronger conviction about what  we have been building for the past three months: an open source billing API, making it easy and seamless to build a custom billing system.

Yes, all companies should be able to bill their customers without going crazy, or hiring a team of 10 billing engineers, or giving away a high cut of their revenue to third-party solutions that are actually only doing half the job.

Here is one of the many comments that illustrate this:

‍

Solving it the Open Source way

When defining our tagline, we aimed for clarity: “The open-source Stripe Billing alternative”. In reality, it’s much more than this. We want to build a complete billing system fitting every single company’s needs: subscription based, usage based, and above all, all the nuances of pricing in between.

Our first principle is that billing is an engineering challenge. Its scope involves numerous teams: sales, finance, marketing, customer success. But the root cause of a billing system’s performance will always revolve around how engineers implemented and maintained it. Often, the billing system will fuel pricing decisions and business process design, not the other way around. As a result, backend engineers are the ones who suffer the most from implementing a pricing grid and its long tail of  complex billing logics brought with it, that are rarely precisely specified.

One of the comments on our Hacker News post describes this phenomenon precisely:

‍

In a world where all pricing grids are different, with tiny but important subtleties, we want our product to bring composability, and to enable a participative approach. We also want to build trust by being open. This is why we share our thoughts around our strategy, open our source code, and also why our product has an easy-to-deploy and open architecture that can be plugged into any application.

We want all companies to have the benefits of home-made billing systems (flexibility, customizability) without the burden of having to rebuild everything from scratch and maintaining the system on their own. Lago and our community are here for that. Pricing and billing rarely gets simpler as a company grows, and no engineer should be on their own to carry this responsibility on their shoulders, especially when their job is to focus on the core product of the company, rather than on the billing system.

In addition to this, from the hundreds of conversations we had with engineers, we also noticed there was a long tail of edge cases that were completely unaddressed by the existing closed-source solutions. Indeed, a closed-source SaaS structurally can’t address what they see as a “niche”: they are looking for mainstream use cases that can appeal to a large segment and justify how much effort they would invest in solving this need. This was another reason why we made Lago open source. Lago is where billing engineers can share, iterate, collaborate on solving the long tail of billing edge cases, so that no one has to rethink everything from scratch.

Where did we start, and what have we built these past three months?  We created a core API, alongside three API clients that you can use (Ruby, Node.js and Python). We’ll keep adding more programming languages to the Client API. On top of that, you can build your billing system with “Lago Front” (made using React), an application to help trigger manual actions such as creating plans, billable metrics or performing, through the UI, any action available via the API. The whole Lago app can be deployed with a simple docker-compose up. It’s only the beginning, but we truly believe it’s the stepping stone to a broader movement.

How much does Lago cost? We are founders and builders too, and we’ve always been infuriated by the “rent seeker approach” of billing solutions. Taking a cut of your customers' revenue, when you are a middleware, is something we’ve always rejected, especially in a pay-as-you-go world where margins tend to drop. This is why the self-hosted version of Lago will always be free and “ready-to-use” for engineers.

Of course, we will need to monetize Lago at some point, to build a sustainable open-source company and keep investing in the product and for the community. Therefore, we also offer a fully hosted version of Lago, “Lago Cloud”, that teams will have to pay for. Its pricing is still an open question, and we’d love to have your inputs on that (the only option out of the table is taking a percentage of our user's revenue). We believe that a “per-event” or “computation” approach could be fair, but once again, we plan to iterate on this with our users, to reach a balance between fairness and sustainability.

You can learn more about AGPLv3, the license we've chosen, in this article.

‍

Embedded billing logics

The Lago API comes with a fully embedded billing logic, solving complex behaviors when you need to work with dates, upgrades, downgrades, pro-ratas, free trials, paying in arrears or in advance. Here is an  overview of what we already automatically calculate for engineers:

Working with dates (trials, pro-ratas, upgrades/downgrades): during billing cycles, the number of days in a month/a year has a very high importance. Instead of calculating this yourself, we developed a system calculating everything on your own. The free trials (in days) are automatically deducted from the final price to be paid, and calculations of pro-ratas are embedded, especially if your customers upgrade or downgrade in the middle of a billing period.

Pay in arrears or in advance: you decide whether a charge needs to be paid for the upcoming month (in advance) or for the past period (in arrears). If the charge is paid in advance, the first invoice is triggered instantly. If it’s paid in arrears, the invoice is emitted at the end of the period. This invoice includes a pro-rata based on the number of days remaining before the end of the billing period.

Coupons: discounts applied automatically to the total invoice amount if assigned to a customer. Coupons can be limited in time or not (applied forever) to a specific customer. We are working on bringing more complexity to the coupons (for instance: recurring over a specified period or applied to a specific charge only).

Add-ons: one-off fee that is invoiced straightaway. Add-ons are very useful for one-shot charges such as a “setup fee” applied once and for all, or a “special customer care” fee paid once a year. These one-off charges trigger their own specific invoice as they are charged immediately.

Generating the invoice: at the end of each billing period, Lago automatically creates the invoice with a breakdown of all charged items and units consumed. This invoice gathers both the fix subscription and the usage-based features. Invoices follow, for each customer, a sequential id logic making it usable immediately. Moreover, this invoice is retrieved as a highly detailed json triggered by a webhook (invoice.created), making it easy to connect to any third party provider (payment, accounting or tax providers). In other terms, if you’re already using Netsuite or Quickbooks to manage your invoices, Lago can send all necessary infos to this tool, you don’t need to change anything.

‍

Usage-based and “hybrid” billing made easy

At Lago, we think the future of billing is “hybrid”: a subtle mix between subscriptions and “pay-as-you-go” features. This is why we built our API to ingest a lot of consumption-based events. These events are aggregated at the end of a billable period as billable metrics.

A simple way to think about this event-driven architecture is: “What can be tracked can be billed”.

To bring the highest level of flexibility required by your pricing models, we defined for now 4 possible aggregation types:

• COUNT(event) = counting the number of occurrences for a specific event
• SUM(event.property) = summing a defined property for a specific event
• MAX(event.property) = keeping the highest value of a property for a specific event
• COUNT(DISTINCT event.property) = counting a specific event over a deduplicated property

Lago automatically calculates the number of units to be charged, and this result might be slightly different regarding the aggregation type you decided to use for a consumption-based feature. We often provide the example of an analytics company providing an API to track pageviews:

‍

Here are the units to be charged based on the chosen aggregation type for a tracked_pages billable metric:

‍

In addition to this, you can charge for these units using different pricing models:

• The standard pricing model: fixed price for each unit;
• The graduated pricing model: evolutive price per unit following a pricing scale; and
• The package pricing model: fixed price applied to a range of units.

We will be adding more options in the coming weeks.

We’ve also created Templates, a website section where you can learn how to reproduce the pricing of some well-known companies with Lago. It gives you insight and tips on how to replicate existing models and adapt it for your company.

‍

Creating the “Modern Pricing Stack”: a team game

Billing systems are often viewed as a monolith, when in reality they belong to a wider “Pricing Stack”. The Pricing Stack is composed of several distinct functions that need to collaborate smoothly together: billing for sure, but also payment gateways, accounting solutions, taxes applications, authorization protocols, cash collection softwares, sales commission solutions, the list can be pretty long.

Getting billing right is one thing (and already a pretty complex one) but the bigger picture is to build a “Modern Pricing Stack” (in echo to the Modern Data Stack) that sets companies for success.

At Lago, we won’t force you to use a specific adjacent solution. For instance, we stand against the “Stripe situation”: not only for its “rent seeker pricing”, but also because when you use Stripe Billing, you can only use Stripe Payments for payments. What happens if you serve a market where Stripe Payments is not so relevant (Latin America, Northern Europe?)? Also, we grew tired of waiting for closed source solutions to prioritize integration features, and we’ve always wanted to have the flexibility and freedom an open API offers. So that’s the mindset we had when conceiving Lago API.

Therefore, whatever tool you’d like to integrate with our billing API, our open architecture already lets you create bridges with your own system, easily. And to make it even easier, we’ll also develop native integrations. Here is what we’re working on:

• Tax management integrations: you can already define a global tax rate or per-customer tax rate within Lago, we’ll add native integrations with tax applications based on demand;
• Sales CRM native integrations: integrating with your preferred CRM and trigger billing actions from it in a 2-way sync (Salesforce or Hubspot);
• Accounting native integrations: integrating with the most popular accounting service; and
• Payment providers native integrations: integrating natively with Stripe Payments, Paddle, PayPal and many more.

To summarize, while these integrations aren’t native yet, you don’t need to wait for us to do so: you can still use our API to connect to these applications.

Also, you can help by:

• Giving your opinion on how we should prioritize these integrations: take a look at our open roadmap here, and request or vote for new features here; and
• Getting your hands dirty and co-building integrations with us:  contribute to our repository, submit issues and pull requests here.

‍

The long road to your hearts

Even if we’re proud of what we’ve built so far, and truly believe it can already be used to build complete billing systems, we know we’re at the humble beginnings of the road. The features needed for a billing system, let alone a complete “Modern Pricing Stack” can be endless, and the related needs are constantly evolving.

This is why we decided to make our roadmap public, so that you would have full visibility on what’s coming soon, and what we plan to tackle in the future. You can interact with us and the community, request features, and upvote some of them directly on Discourse. This really helps us build something impactful.

Also, have a look at our API, test it out, give us some love, stars, and contribute to our GitHub repository!

To conclude, we’d like to share with you our long-term product vision: becoming the billing standard for the next generation of software companies.

These companies are often referred to as “product-led growth” companies (who knows what other shiny terms might be used in the future). They often start with a self-serve go-to-market motion. In that case, their pricing is partly or fully based on usage (and sometimes complex metering needs), and the billing system is fully automated based on standardized pricing plans.

Later on, they add a layer of “Sales” people to expand the annual contract value of the existing user base aiming at upgrading an existing account to an Enterprise level plan for instance. This transition usually brings loads of complexity in the organization, and the flexibility of the billing system is often to blame. It formerly only had to manage a finite number of preconceived plans, but it now has to deal with quotes (that are iterated on several times), a myriad of exceptions, negotiations for ad hoc situations, flexible payment terms, custom commitment periods, complex sales commission calculations, cash collection issues, and very specific internal workflows.

As a result, billing systems built for self-serve don’t play well with the “Enterprise Sales motion” of PLG companies (and they all aim at going upmarket), leaving a huge gap in the market. The two worlds need to collaborate, as PLG is the go-to-market motion that has proved to be both efficient for vendors and popular among their users. That’s what our product is solving for in the long term, in an open and transparent approach.

It’s only the beginning, and we can’t be more excited for the years to come. Let’s keep in touch!

• GitHub
• Our discussion forum
• Email: [email protected]
• Schedule a demo here