Billing systems are a nightmare for engineers

No. No, spelled F-U-C-K-N-O.

Should you compare and contrast off the shelf solutions, test one or two, and slowly expand its use to cover more of your business? By all means, yes.

Should you develop an in-house custom variant after that? Still no. For billing or anything else.

Even a pure tech company like Google should not vertically integrate everything. You quickly end up wasting time making horrid systems instead of generating your main business revenue.

"Oh, but our needs don't align with the way the industry standard third party systems work." That's a symptom of the disease. You won't cure it by enabling the virus to proliferate even further.

People who don't execute I.T. low level changes mistake computers for magic. Yes, computers can do a lot. But even the tiniest feature takes an incredible amount of focus, cost, development time, maintenance time, headaches, and gnashing of teeth to accomplish. The magic is that it looks easy, from the user's point of view.

Let's put it bluntly: We can draw a direct line from third party systems with multiple businesses as customers, with cost savings. It's far more likely to be a complete waste of resources to in-house a new software system.

Maybe you don't have a name for the kind of system you want or need. That's okay. Keep assuming it's probably already out there, and continually search for it. Googling is cheaper than building.

"But we can build it better than them because..." Please, that's the fallacy of exceptionalism. Remember, every company wants to believe they're truly pioneering, talented, and logistically capable of doing all the things. Don't spread yourself so thin. Keep the lights on. Grow your customer base. Everything else is a pipe dream.

"But the third party systems suck."

Yes, they very much suck. And yet the cheapest path to success is pushing them to un-suck their product. Not starting from scratch to create a second, even more immature product.

Frankly, computer systems are already quite flexible. You can often bend an existing one to fit your needs. This happens with Jira, for example. They customize it until it can't function at all anymore. But this sad extension situation is still cheaper and more effective for conducting business than invention.

If you truly believe a new kind of system needs to be built, go and start a new software company. Or pay a software vendor to do it. (Software vendors, just take their money, smile, and nod.) But for Warren Buffet's sake, don't spend a dime on a new line of code if at all possible.

But I'd push back on the 1 subscription per customer idea. Consider any physical fulfillment business, where you have an optional annual membership (amazon prime, costco, whatever) and N subscriptions of varying frequencies for physical products.

It doesn't make sense to roll these into a single subscription on the backend (unless the periodicity happens to line up perfectly, and even then there's a heated debate, since you still probably want them to be separate charges).

You can go down the route of creating N "virtual" customers for each "real" customer, but it doesn't really solve the problems, because these N customers have a complex relationship with each other that you need to encode and manage.

Hence, the name of this post :). It's definitely not easy!