Note OP makes a billing product (OSS, granted) so is motivated to characterize the field as complex and hard. In reality billing is just like many other processes humans engage in. For sure it's more complex than computing prime numbers, but hey try writing software to capture medical services processes :) In the end this is exactly what engineers are supposed to do: figure out ways to model/capture/represent complex processes and data.
Or better, buy a billing system instead of inventing one inhouse. Billing is hard to do correctly. For one thing it interconnects with so many different platforms in your company. For another thing, the cost of fucking something up is high--people don't exactly like seeing mistakes in their bill. Hell, think about tax... you wanna deal with that shit?
To do it "correct" you've got to have people who truly understand accounting concepts like double entry bookkeeping, financial reporting, cash vs. accrual, financial regulations, auditors, etc. Unless your company's product is billing, good luck hiring an engineer who knows this shit.
But trust me from experience. Don't build your own billing system. There are several good ones out there that will grow with your organization. Buy one.
Similar experience in some companies in my CV. Billing systems aren't fun to maintain, develop nor debug. They take a non-trivial amount of time when done wrong and if you are building one in-house you'll inevitably run into some mistake.
Buy a billing system, it'll save engineering hours having to deal with it and if you choose right they'll scale with your company.
Not only will you get mistakes, but much worse in my opinion is the opportunity costs involved. You will always be playing catchup to add new (very basic) features that the real packages offer right out of the box.
For example if your homebrew thing doesn't handle price changes, that might take you quite some time to build in functionality. That time spent is time where you couldn't quickly react to market changes, which is money left on the table. Had you bought something that supports a simple use case like "change the price", you'd hit a couple buttons and boom... your product now sells for a different price.
A companies billing system is one of the most important systems in the company. It is literally how money gets into your pocket. If you build it yourself, you will sign up for pissing away a ton of time writing code that literally will let you collect more money from your customers. Had you bought something, you'd just fucking go do the change right away and collect more money from your customers almost instantly.
I totally agree with you, I had to work on the Qonto's billing system (that Raffi is talking in the blog post) and it wasn't fun to maintain. I remember the pain it was to change anything without breaking the whole system, not because the system was bad, but because it's complex and when you build it in-house, you will certainly take some shortcuts that makes it not so flexible!
Could not agree more. Even building your own billing system atop something like stripe is super complicated. Rebill dates, proration, upgrade/downgrade, cancel, updating card on file, refunds, charge backs. These are all things you end up patching as you come across them.
There was a really nice and simple to use billing software that was built on stripe. I used it for a handful of products after I decided to never roll my own again. It is gone now. GoDaddy bought them and shut them down.
I think Stripe checkout is a valid solution now if you don't mind sending your customers away from your site, but I haven't played with it since they rolled it out.
As you say; billing system is tip of an iceberg. There's reconciliation, settlement, payouts, tax, financial reporting and what not. For a small mom-and-pop store, sure build it. But for any half-complex business billing is a rabbit hole.
I'm not sure this comment is exactly in good faith though-- OP does make a billing product but as a result is also uniquely qualified to provide insights into what can make it hard.
This isn't OP trying to claim it's the most difficult problem to solve from an engineering standpoint. Merely why it's hard.
Of course engineers solve problems, hard or not. That's not really being debated here is it?
Hi dboreham, I'm one of the co-founders of Lago here (the OP).
I completely agree with you, billing is not the most complex process of all, medical services may be of higher complexity.
Our post was meant to highlight the discrepancy between the perceived low complexity (lots of teams who have never done it think it's simple) and the reality, with our own experience building a fintech.
I think for some processes (medical services? I'm not an expert in this field to be honest) people might suspect it's going to be challenging.
That was our intention. Basically we think no B2B saas should be building billing themselves, unless they are 300% sure their pricing will always remain subscription based only, and very simple (same amount every month).
If it’s as annoying as translating human processes into code, I can see how they’d want to standardize it so they’d never have to do that particular part again.
Then again, if you make it too customizable, you end up with current single sign on solutions.
I have no vested interest in selling billing products, and my experience is that billing is somewhat unique in the delta between how hard people who have never done it THINK it is, and how hard it actually is. There are many hard things that appear simple, but time and time again I have seen inexperienced engineers be caught off guard by just how much harder billing is than it looks.
This feels like a good moment to mention my most embarrassing bug which was, of course, in a billing system. I had written code to handle the overdue billing of customers' usage on an internet telephony service. The code seemed to work great in QA so we went ahead and pushed it to production.
A couple days later we got an angry call from a customer whose card we'd maxed out. The final stage of the process was to adjust their bill by the amount that they paid, but there was a sign error in that adjustment so instead of lowering their balance by the amount paid, we increased it. As a consequence, for a user with, say, a $50 balance, we kept doubling the amount that we charged them each day.
I think this is a great article and sales pitch for the company, since a lot of the comments have been anecdotes of how its actually even HARDER than the author leads on.
