Building your home-grown billing system is a very appealing idea. And in some cases, it’s the right decision.
The thought process can be the following:
- It’s a fun internal tool to build! Won’t take that long.
- When it’s finished, I’ll work on the core business.
- My needs are so unique anyway, homegrown is the way!
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.’
Vincent Pochet, Senior Backend Developer at Lago, built the home-grown billing system of Qonto (a $5B Fintech in Europe) from pre-launch to series D. Quite amusingly, he was told he would be staffed on billing for only 3 months and ended up working on the billing system for 4 years, and was soon joined by a dozen other team members. Vincent’s words?
‘Now, when someone asks for advice about their billing system, my answer is clear: DO NOT build it yourself.’
Myth 1: It’s a fun internal tool to build! Won’t take that long.
Billing is a nightmare for engineers. Think about dates (leap years, February only holding 28 days, etc), upgrades and downgrades, usage-based computations, taxes, for instance.
Here are the most common billing engineering nightmares we identified, which triggered an intense conversation on Hacker News here (more than 350 comments).
Myth 2: When it’s finished, I’ll work on the core business.
Billing is never finished. Unless you never iterate on pricing, launch new features, new plans, new territories, define promotions and packages, etc. And unless your company doesn’t grow.
If you’re planning for growth, read this story about the 100K customers migration for a “simple switch” from an anniversary billing period to a calendar billing period. It’s one of the native features of Lago by the way.
Myth 3: My needs are so unique anyway, homegrown is the way!
Last but not least, engineers often think they have two options:
Option 1: a vendor addresses 100% of their billing needs.
Option 2: they build 100% of the billing system themselves.
This most often leads to disappointment, billing needs are often made of a long tail of edge cases: is it worth building and maintaining a whole system for these edge cases?
It’s with this paradox in mind that we built Lago in an open source approach:
- You can pick building blocks: metering, plan management, prepaid credits, credit notes, coupons
- And build on top of them to address your edge cases
Open Source enables you to have an exact understanding of how we built Lago, and also contribute or fork our API to customize it as much as you need.
Here is how the resources needed compare:
Final words, not from us, but from two technical leaders who had to scale a home-grown billing system at two unicorns:
Billing has millions of edge cases. But it’s also a ‘talent nightmare’. No CTO wants to staff their engineers on billing, and no engineers want to work on this on the long term.I just wish Lago existed five years ago, so that my team could build on top of their API and go back to building our core product asap.
Gabriel Klein, CTPO at Masteos / ex VP Engineering at Qonto
I wish Lago existed when we started Algolia.We've revamped our billing stack three times and even went through a failed implementation with Zuora. We totally underestimated the complexity of billing at the time, and our needs were too specific for closed-source vendors.
Nicolas Dessaigne, Co-founder at Algolia / Partner at Y Combinator