Problems with homemade billing systems

You could say the same thing about literally any 3rd party software or service you purchase. "Why use cloud services to do anything?" etc.

Sure this thinking will hold for some things, but chances are that for something as standard as billing you're not going to be implementing some revolutionary feature that gets you more customers. On the other hand, if you mess up billing because you rolled your own system that doesn't have many standard options that a mature OTS system would offer it can lose you potential customers, because for months at a time you're stuck building the most mundane and standard things like an annual plan that could be used to better appeal to buyers.

For billing, a one of the most standard things ever for a business, you simply take a small amount of time to survey the OTS options and compare features. Any you know what? There's an excellent chance that buy actually getting a comprehensive look at features offered by such options you will learn about the types of things you will absolutely want to do in the future. Things that, in retrospect, seem like obvious oversights, such as an annual plan. You'll see features like that in your survey and say to yourself "Oh, yeah, that's something we may definitely want in the future, lets put that on our requirement list for a final choice."

E.g. one thing that worked well in the systems I've worked on was to break things into small state transitions, very firmly document the allowed states and their transitions, and log every transition to the database. Wherever possible (anywhere that didn't interact with external API's, and sometimes even when they did) we'd aim for state transitions to be idempotent. When they weren't, we'd seek to reduce the non-idempotent call to an external dependency to just that call as a separate state transition.

When something very occasionally went wrong, we could trace things in detail, and pinpoint it, and most of the time we could safely replay transitions around whatever went wrong until we could see what had happened.

It wasn't difficult to build these systems that way, but it was tedious, and something where it's easy for people to be tempted into shortcuts.

As for scaling, you spit out events for rollups, and can shard invoice generation. We handled millions of revenue on a machine far less powerful than my laptop today. Scaling really would not have been up there for me.

To #3, maintaining old pricing isn't generally that hard. Very few people drastically change how they account for usage, which tends to be the most complicated billing scenario. They tend to change amounts and periods and thresholds, which should be data, not code.

With respect to a team, I agree. One of the places I worked on billing was Yahoo. At the time it wasn't just one team, but several - my team (responsible for Europe) existed largely because the European finance and product teams didn't trust the US payment services team to take their requirements seriously enough and so wouldn't let them near the European premium services... Billing isn't something you want to do yourself unless it's either a core competency or you're big enough to have to deal with that kind of bullshit.

(As for size of teams, I've built a billing system with 2 people, but I've also worked on billing systems managed by 50... You really want to have a good idea whether you're likely to end up towards the former or latter before you go ahead...)

They would have to solve the same problem in a generic way. (add 10 more years)

> we had to migrate off

Adds to the fun doesn't it? My missing features hacked around previously exploded into an almost impossible puzzle.