Problems with homemade billing systems
getlago.com
Problems with homemade billing systems
1–10 of 105 posts
Re: Problems with homemade billing systems
#2Good article, and I generally agree that people are too quick to say “Ahh, this looks like a two week project” and ignore broader complexity. I’ve definitely seen a fair amount of that.
My question is, how do I know that the OTS solution would actually be much better? For example, OP describes some tricky migrations from one type of billing to another, or complex grandfathering schemes - how would you have any guarantee that your third party solution would be able to support those? At least if it’s in-house you can implement the needed functionality eventually - if it’s third-party it might just be flat-out impossible.
Re: Problems with homemade billing systems
#3I think it depends on the business you run. To be honest, I would not mind building a billing system if my company grows to an unicorn!
Re: Problems with homemade billing systems
#4Good article, and I generally agree that people are too quick to say “Ahh, this looks like a two week project” and ignore broader complexity. I’ve definitely seen a fair amount of that. My question is, how do I know that the OTS solution would actually be much better? For example, OP describes some tricky migrations from one type of billing to another, or complex grandfathering schemes - how would you have any guaran…
Indeed. Very often organisations tend towards buying solutions without appropriately gauging the situation. One easy example from IT is buying servers vs renting them, but fortunately it seems that IT people have found the, for some uncomfortable, balance of "it always depends", and the analysis might turn multifaceted pretty quickly.
I also feel that people often discount the cost of up top decisions that people below don't like.
Re: Problems with homemade billing systems
#5Having gone through /exactly/ what this article is about, I know the pain. But I will point those that don't read the article to the last paragraph:
> We considered implementing an off-the-shelf billing solution but there was nothing flexible enough and the switching costs were too high. Algolia also tried to migrate to Zuora before backing out and rebuilding their billing system for the fourth time.
Most (all? I have yet to find one) off-the-shelf systems are not geared towards everything businesses want to do with their billing. If you take the author's advice and choose one of these systems early on, you will have the exact same headaches. Either the system simply won't let you do what you want to do or the system /will/ let you do what you want to do with custom or hack-ish solutions that reproduce the custom-solution problem, but in someone else's system. Those that implement broad swathes of billing functionality are so complex, they make /everything/, even the most basic stuff, hard.
BTW, when I say I know exactly how the author feels, all of what they described we encountered and implemented. We even looked at a migration to Zuora and came away with the same conclusion (also: really freaking expensive). We even had a new product that we setup on a third-party billing system, and we ran into the flip-side of the problems; we were not able to implement some billing functions we needed and we had to migrate off.
Re: Problems with homemade billing systems
#6Like with everything, wrap your billing in a layer and when you grow enough you put your billing under it if you need it or switch to a different provider without changing your codebase.
It's not wise to outsource parts that are essential for your business, because: 1. you depend on 3rd party service for a getting paid 2. your operations cost may rise or the service may change terms/functionality
Re: Problems with homemade billing systems
#7It looks like one core issue was designing the system around pre-determined bounds (monthly, yearly, etc). This happens in lots of systems and isn't specific to billing. A job scheduling system will have the same problem (we built it to track seconds and now they want us to track calendar dates!).
Re: Problems with homemade billing systems
#8I built my billing system on top of Django and it's used in 2 online services for a few thousand users and hundreds of invoices a month.
You have to be mindful of some edge cases, but if the scope is kept narrow, it's doable. The added benefit is the flexibility to fit it to your use case. And with Python, you get many high-level libraries, e.g. for decimal calculations and PDF generation.
Re: Problems with homemade billing systems
#9Good article, and I generally agree that people are too quick to say “Ahh, this looks like a two week project” and ignore broader complexity. I’ve definitely seen a fair amount of that. My question is, how do I know that the OTS solution would actually be much better? For example, OP describes some tricky migrations from one type of billing to another, or complex grandfathering schemes - how would you have any guaran…
HAHAHA, my estimate was 2 weeks. This was 6 months ago. It is now a marvel of engineering with most of the 100 000 edge cases covered. You should read that as: not battle tested on (insane) users. (I'm so looking forwards to that) I estimate 2 years to completely finish it, give or take a decade or two.
Re: Problems with homemade billing systems
#10I built my billing system on top of Django and it's used in 2 online services for a few thousand users and hundreds of invoices a month. You have to be mindful of some edge cases, but if the scope is kept narrow, it's doable. The added benefit is the flexibility to fit it to your use case. And with Python, you get many high-level libraries, e.g. for decimal calculations and PDF generation.
My experience is that the scope is never kept narrow, which is exactly the same that the author is describing.