Engineers' billing nightmares
Eh, I've worked on billing, payments and salary systems, some of these problems are not that awful. It sounds like the source of much of it is just classic underestimation of the amount of work & complexity to implement something. If someone gets away with saying "shouldn't be hard right?" to the point it dictates the size of the team (2 engineers? That's barely a team), then you're going to have problems.<p>Some of it comes down to picking the right tool for the job. The article doesn't touch on technology choice at all, but it matters. When I built a salary system, I deliberately chose a tech stack that had good numeric calculation support (so not JavaScript). These choices matter and have lasting impacts on your project. Same thing for handling dates, for example here .NET and Java have excellent standard library support for everything date related. Other languages, not so much.<p>Another point the article talks about is change: companies change how they bill over time; customers change their plans. Again there's nothing specific to billing systems here. All systems have to deal with change. All systems beyond a trivial size end up with migration scripts, and sometimes those scripts end up being productized and becoming buttons in dashboards.<p>I guess my main point here is don't underestimate what might seem to be an "ancillary" product when it's an essential service that makes sure cash keeps flowing. Treat every important project with the care and respect necessary. Allocate resources properly. Don't underestimate. Oh, and don't underestimate.