Why billing is not just 'Build' or 'Buy'

Open source disrupts the ‘Build vs Buy’ dichotomy and our friends at Airbyte were the first to articulate this phenomenon, for the ETL industry (see here).

How does this analysis hold for the billing space? Here are our thoughts.

‍

Our two personas

We started publishing content a few months ago and hit the front page of Hacker News several times. This post in particular really resonated with the tech community: ‘Why billing systems are a nightmare for engineers’.

As a result, we keep getting inbound messages from a variety of companies. Among them, we identified two personas:

1. The early-stage company, which has a hybrid pricing model and for which speed is the priority. They want to buy a billing system to focus on growing their core business; and
2. The series C or D company, which has an existing home-grown billing system and wants to upgrade it, while saving engineering resources.

The second persona is really interesting as:

• They understand how complex billing is ‒ which is not always the case with early-stage companies, as they haven’t faced these issues and/or because their pricing grid is simpler at this stage;

• They’ve tried several times to implement an off-the-shelf solution but their pricing is so complex that it does not fit any software; and

• They usually end up accepting what they think is inevitable and staff senior back-end engineers to build and maintain their home-grown billing system.

It’s not unusual to see billing teams of 10+ full time employees in these companies. Engineers don’t necessarily love the job or have experience in this field. Finance and Operations executives keep pushing for new features, reporting tools and integrations, while Growth teams constantly want to iterate on pricing. In addition to this, the CEO feels that these talents could be put to better use.

As we built the home-grown billing system of Qonto, we experienced this firsthand: what started as a three-month project for one engineer ended up mobilizing up to 12 people full time.

It’s a typical conversation that we have with engineers on a daily basis. Here are Kevin’s words, former VP Engineering at Scaleway, one of the European leaders in cloud infrastructure:

‍

‘On my first day, I was told: ‘Payment will come later, shouldn't be hard right?’

I was worried. We were not selling and delivering goods, but SSDs and CPU cores, petabytes and milliseconds, space and time. Instantly, via API. Fungible, at the smallest unit. On all continents. That was the vision.
‍
After a week, I felt like I was the only one really concerned about the long road ahead. In ambitious enterprise projects, complexity compounds quickly: multi-tenancy, multi-users, multi-roles, multi-currency, multi-tax codes, multi-everything. These systems were no fun, some were ancient, and often ‘spaghetti-like’.

What should have been a one-year R&D project ended up taking seven years of my professional life, in which I grew the billing team from 0 to 12 people. So yes, if you ask me, billing is hard. Harder than you think. It's time to solve that once and for all.’

‍

How does open source solve this?

We created a framework to compare the ‘Build’ and ‘Buy’ options.

It was built with the Fintech industry in mind, however, it applies to any product-led SaaS, especially if they provide embedded banking services (e.g. a vertical SaaS that provides wallets, cards, etc.).

We chose fintechs because they are a great example of hybrid pricing (i.e. subscription fees + usage-based charges):

• Fintechs usually have the luxury to debit their own wallets,so they can bypass payment processing fees and payment processing failure rates. Example: a neobank called Banco will debit the ‘Banco wallets’ of its customers directly, instead of asking them to pay via credit card for instance. You don’t have to be a neobank to be able to do this, many vertical SaaS offer embedded payments now and can therefore debit their own wallets as well;

• They often charge on a pro-rata basis: let’s imagine that you start a subscription that includes a physical card, then 10 days into the month, you order a second card that costs $5/month as ‘overage’, then this charge will be calculated on a pro-rata basis;

• Foreign exchange fees require variable rates and a commission; and

• ATM and FX fees need to be debited instantly, while invoices are sent monthly.

First, let’s compare Lago with traditional closed-source billing solutions: Chargebee and Stripe Billing (Stripe’s billing module, not their main payment processing product Stripe Payments ‒ more information here).

‍

Then, if you’re considering building your own billing system from scratch because none of the closed-source solutions seem suitable, it’s worth taking a look at the table below.

‍

*Estimated cost for a senior engineer: $150k/year minimum

‍

Onwards & Upwards

If you’ve never built a home-grown billing system, it may seem fun at first: you don’t know the unknowns and it would be great to say that you solved this problem in a few weeks or months, all by yourself.

But your company and pricing are living organisms.

Sooner or later, you’ll need to develop new billing features and integrations, and you’ll need to maintain them. Unless you want to build a ‘billing engineering’ team as your business grows, you should consider a solution that scales with you, while being composable and loved by your engineers.

You might want to bet on incumbents such as Chargebee or Stripe Billing and their ability to evolve quickly. Although they could do so (in theory), these platforms have a vested interest in serving their installed base: subscription companies and e-commerce platforms. On top of that, they take a cut of your revenue, so costs increase as you grow. Both factors are incompatible with the more complex pricing models that are now emerging with product-led growth.

And if you still want to take up the challenge of building your billing system yourself (engineers love solving complex problems), you can always use Lago’s library to get started.