Live data from Hacker News

Problems with homemade billing systems

getlago.com

81–90 of 105 posts

Re: Problems with homemade billing systems

#82

It 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!).

Navigating this challenge involves the ever-changing boundaries of billing. Initially, you build a monthly billing system, only to find that your team requires a yearly one, which seems relatively straightforward. However, complications arise when you introduce usage-based billing, incorporating weighted values akin to storage, layered on top of a quarterly plan. This complexity is further exacerbated when custom billing structures are needed for negotiated contracts, adding another layer of intricacy to the mix.

Re: Problems with homemade billing systems

#83

Billing is one of those problems that seem deceivingly easy. Just talk to someone who has worked in telco billing and learn about the 4 horsemen of billpocalypse: metering, mediation, accounting, billing.

You can add taxes and negotiated contracts to the list tbh

Re: Problems with homemade billing systems

#84
post #71

How about accounting, would anyone recommend a modern open source accounting system that would be better than in-house?

Not necessarily open source, but there are a lot of third party tools for accounting (netsuite, quickbooks, xero). And I would say they scale 100x better than an in house tool

Re: Problems with homemade billing systems

#85
I've worked on telco billing systems in the past and the generally accepted metric in the industry is 70% of billing systems projects fail. Not fail as in "did not completely meet requirements or expectations", fail as in "did not deliver anything whatsoever".

Re: Problems with homemade billing systems

#87
post #8

I 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.

I built a billing system for a web hosting company in PHP, almost 20 years ago. This was for a few hundred users. There were a couple of edge cases, but nothing incredibly challenging.

Was it a basic subscription model or have you faced challenges with taxes, usage-based components, entitlements, grand fathering?

Re: Problems with homemade billing systems

#88
post #2

Good 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…

Sometimes unlimited choice is a vicious thing.

With the power to modify anything, people will make decisions and choices with serious consequences and benefits that may or may not be tangible, or worth the squeeze.

I’ve spent most of my career working in and around government, and poorly scoped or framed legislation costs billions because it drives customization and development. The business and engineering impacts of those decisions are often not appreciated.

If you work for a corporation, and you have a off the shelf billing system that fundamentally does what is needed… you have a chance of using ROI or some other metric to save the (expensive, hard dollar) customization for when there is real value.

The other thing is that sometimes these custom systems create customer problems in the name of “helping”. I’ve had many times where some legacy SKU or billing model, left in place to make my life easier instead made things much much more difficult down the line.

Re: Problems with homemade billing systems

#89
post #8

I 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.

The use case is tiny at the beginning but the complexity increases over time to be honest. The scope is never as narrow as you think at the beginning of the project. Libraries are great, they can help you implement faster, but if the company grows, you will need an entire team to build and maintain it

Re: Problems with homemade billing systems

#90
post #48

The point the article makes to me (as a leader) is “keep the billing model simple, honest and stick with it”. The cost of change is high, and the value isn’t to the people getting the work done. My peers would likely see this as “naive” and extoll the need to “sell to the buyer”. I see it as being value focused, and keeping the “business needs” rational, and in line.

When you don't understand the complexity of billing (revenue ops, top management or marketing), you often end up adding more and more complexity, and engineering teams have no choice. They have to build new billing features
Post reply on HN