Those are all problems which have been "solved" by many companies. I'm sorry but none of this screams complex to me, all your problems have 2-3 "correct" choices, or you could just copy what almost all big companies do.
The whole point of TFA is that billing systems are way more complex than they appear to be. If you're trying to build a billing system, how do you "copy" what these big companies do, when most of the effort is neither obvious nor visible?
It's easy in theory: 'just do it', 'just copy',
BUT the challenges are in
- the tiny details (that can have a huge impact: we're talking 'billing' and 'money' here)
- the maintenance: it's a living organism: you will inevitably change your pricing, your payment processor, the way you bill, your back-end/front-end etc
> The whole point of TFA is that billing systems are way more complex than they appear to be.
Technically the point of TFA is to market billing software. Billing systems are complex in that they can consist of many different moving parts, but billing system are also simple in that they are easily understood. Billing has to be easily understood, else you'll quickly scare your customers away. Complexity and simplicity are not necessarily at odds with each other. The meat of TFA is mostly about how billing systems can quickly become a time consuming endeavour which again isn't at odds with simplicity.
I disagree. Billing has to be correct - that’s billing rule #1. You can have an easily understood pricing plan, but implementing that plan correctly and consistently in a way that you can defend and audit can be very complicated.
Just take the simple example of implementing anniversary billing for a customer who signs up on the 30th of the month. What date do you bill them when the month has less than 30 days? What about when it has more than 30 days? What about when your customers are spread through 4 time zones? What about when daylight savings starts and ends? Do most engineers understand time and time zones well enough to get this right?
These questions are fundamental to correct billing at any kind of scale, and the answers are not simple, or at least I don’t think they are.
> but implementing that plan correctly and consistently in a way that you can defend and audit can be very complicated.
We established earlier that billing is likely to be complicated, but that doesn't mean it isn't simple. Simple things can be complex. Simple refers to ability to understand, while complexity refers to scale of interconnected parts. They are not at odds with each other.
> the answers are not simple, or at least I don’t think they are.
I think you can make a strong case that business isn't simple, but billing systems only need to serve the needs of business after business has already figured things out. You cannot bill at all, even without a formal system, if you haven't answered these questions. A billing system merely needs to adopt the answers that are already understood.
> billing systems only need to serve the needs of business after business has already figured things out
Billing is a fundamental part of your product and your GTM. Getting it right gives you an advantage, especially in terms of trying different approaches. Getting it wrong can be a burden on the business, especially if you find out that you need to re-price.
...or you could just copy what almost all big companies do.
This is a dangerous strategy for a startup. A big company can afford to make a mistake and fix it even if it costs tens of millions. If you copy their mistake before anyone has realised it's a mistake you probably won't be able to afford to fix it.
It's also very likely you'll only be able to copy the externally parts of what the big company does, without really understanding why or what's going on behind the scenes. Really, you're advocating cargo culting a solution. That's a bad idea.
Right! The decisions and complexity are all hidden. Billing has to look simple otherwise people wouldn’t pay for stuff.
Take anniversary billing, it seems so simple, just store the billing day-of-month in the database and run the billing using the sql:
select do_billing(customer_id) from customer where billing_day=extract(date from current_date)
And this works great in December and January, but if you don’t have good financial controls you might miss the fact that you’ve dropped an entire week’s worth of billing by the end of the following year.
