Yeah I can agree. I made custom integration with Chartmogul and it was a nightmare. But we did it! And now I feel like real engineer
Billing systems are a nightmare for engineers
131–140 of 372 posts
Re: Billing systems are a nightmare for engineers
#132Just wait until you meet billing's angry roommate: invoicing. In the US, an invoice is just a weird PDF that you might glance at before sending off to your accounts payable team. But in other countries, especially those that use VAT style taxing systems, an invoice can be a legal document that expresses costs and taxes in a legally prescribed way for accounting purposes. Many countries have prescriptive rules over ho…
> You might be sending a truckload of expensive accounting papers to your customer every month, one per transaction. And each of those pages was printed using government prescribed software from oddball vendors you must use or else.
I guess that's good for employment numbers? There's really two ways to create jobs, innovate or regulate. The US and the EU have apparently chosen very different paths. With every country having it's own special snowflakes laws, there's a reason EU founders always try to come to the US first.
Re: Billing systems are a nightmare for engineers
#133Once upon a time I was the first product person at a now-decacorn, and my first task was fixing the billing system. It was quite the monster, and we ended up implementing a combination of Zuora and an internal system, as there were some parts of the billing model Zuora couldn't handle. I came away from this with one big lesson - if you're considering a complex billing model, consider the engineering implications firs…
Yes, this is a big thing - there needs to be a clear model of how variable pricing and discounts are going to work in this company, with the sales team being able to apply the actual amounts of any prices and discounts, but not arbitrarily changing the model.
It doesn't work when the model is too simple or restrictive, which will simply result in the model being violated; you do need at least the ability to customize pricing for individual customers, and for specific invoices, but other than that the decisions (e.g. whether you apply invoice discounts as percentages or specific amount or both) can vary but you just need to pick any reasonable option and stick with it.
Re: Billing systems are a nightmare for engineers
#134Earlier quoted context omitted.
Have you looked at existing solutions? Why did not they fit?
Not the OP, but anybody who has built a deep integration with any billing provider (inclusive of Stripe) knows there are some bodies buried, although you typically don't discover them until you're late in the game. 90% of your use cases are covered, and with excellent UX and docs to boot. But that sweet 10%! --- For a concrete example, Stripe has a very nice "subscription" abstraction that makes it easier to operate…
I think it's easier for billing systems to have 1 subscription for 1 customer. The reason behind this is mainly because you can apply several prices to the same feature belonging to two different subscriptions. Stripe does not work on it because they might consider this as a edge case.
When you look at usage-based billing, even if a billed feature is linked to consumption, it needs to be related to a subscription given the fact that this feature can be priced differently for several plans. Every company has a singular pricing model in mind and it's hard to have an all-in-one model fitting all the needs. Even when we built internally the whole system for a fintech back in 2016, we had some edgecases creating conflict inside the company.
Re: Billing systems are a nightmare for engineers
#135Once upon a time I was the first product person at a now-decacorn, and my first task was fixing the billing system. It was quite the monster, and we ended up implementing a combination of Zuora and an internal system, as there were some parts of the billing model Zuora couldn't handle. I came away from this with one big lesson - if you're considering a complex billing model, consider the engineering implications firs…
Yes, this is a big thing - there needs to be a clear model of how variable pricing and discounts are going to work in this company, with the sales team being able to apply the actual amounts of any prices and discounts, but not arbitrarily changing the model. It doesn't work when the model is too simple or restrictive, which will simply result in the model being violated; you do need at least the ability to customize…
Yeah, this is tough because when the VP of Sales knows that one particular change will close the deal, they're going to push for it no matter what the cost. In reality it may be better from a big picture perspective to give a concession that is actually better for the customer and worse for the company than x as it relates to that particular deal, because the larger concession fits within the current billing system with no custom work, so the overall cost to the business is less.
Re: Billing systems are a nightmare for engineers
#136Note 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…
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).
Hope I helped clarify!
Re: Billing systems are a nightmare for engineers
#137Earlier quoted context omitted.
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…
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.
Re: Billing systems are a nightmare for engineers
#138Note 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…
[deleted]
Re: Billing systems are a nightmare for engineers
#139Earlier quoted context omitted.
I'm Anh-Tho, one of Lago's co-founders here. Thanks for sharing! What did you do then? I'm curious!
Hey, Anh-Tho, just as a point of feedback, since you're leaving a lot of comments in this thread, it's not necessary to introduce yourself in each one. Most folks will be scanning the whole thread and seeing your introduction gets repetitive and breaks the conversational tone and makes it overly commercial. Thanks.
Noted thanks! It's my 1st post on HN, so I appreciate the feedback.
Re: Billing systems are a nightmare for engineers
#140Note 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…
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.