3 ms·
I would instead say - commit properly to building your billing systems as a major and ongoing project, don't dismiss it as a 2 week "fun" side thing. Not convi
by brianmcc 3y ago
I would instead say - commit properly to building your billing systems as a major and ongoing project, don't dismiss it as a 2 week "fun" side thing.
Not convinced any 3rd party product is going to have the flexibility to support ongoing innovation. If anything it's more of a case for in-house expertise and resource. Find some folks who want to be the billing guys!
Disclaimer: I built a large in-house billing system :-)
- agos 3y agosee also: e-commerce systems. Hard to build, a lot of work, but way better than any 3rd party
- calvinmorrison 3y agoInterestingly, fastmail just flipped to having an external billing system after years of maintaining their own. AND when they bought POBOX they got that whole billing stack as well. I can imagine the nightmare but also the relief after exporting all of that work to another company. perl billing system: https://github.com/fastmail/Moonpig https://github.com/fastmail/Moonpig
- re-thc 3y ago> Interestingly, fastmail just flipped to having an external billing system after years of maintaining their own. Would have nothing to do with your or someone else's decision. And Fastmail may or may not have made the right decision. It's hard to say. There are no simulators or time machines to gauge the impact anyway. The most likely answer is preference and available skillset in the area. I've seen managers that absolutely want to self build and those that never want to maintain anything as much as possible (by offloading).