Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Problems with homemade billing systems

getlago.com

Post reply on HN
Print view View original

31–40 of 105 posts

Re: Problems with homemade billing systems

#31

Post by re-thc »

jasode wrote: post #23
542458 wrote: 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…

>, how do I know that the OTS solution would actually be much better? For example, [...] how would you have any guarantee that your third party solution would be able to support those? The business (employees in the accounting dept and/or consultants) do a "fit-gap analysis" when evaluating potential software: https://www.google.com/search?q=fit+gap+analysis For the "gaps" of missing functionality, look at either : (…

> Well, he was 20-something at the time and naive about the complexities of financial accounting software for a global business. He must have eventually realized the true scope of the problem because instead of building in-house accounting software, Google bought Oracle Financials.

How do we jump to this conclusion? Did he realize the true scope of the problem or was it just left to someone else once Google grew in size? It doesn't even explicitly say how Oracle Financials came to be at Google.

> because their internal IT teams never got around to the "eventually" option.

I doubt that's really the case. Same with how cloud came to be. The sales people promised massive savings i.e. bonuses for management and here we are.

Re: Problems with homemade billing systems

#33

Post by bluGill »

freefaler wrote: post #6

Like with everything, wrap your billing in a layer and when you grow enough you put your billing under it if you need it or switch to a different provider without changing your codebase. It's not wise to outsource parts that are essential for your business, because: 1. you depend on 3rd party service for a getting paid 2. your operations cost may rise or the service may change terms/functionality

You always need to outsource things. Unless you live on a desert island alone some things are out sourced. Most of us out source barter to a government run cash system, which we then further outsource to various banks.

While out sourcing is a risk, it is also an opportunity to offload the hard work. You need to figure out what is worth doing yourself; what you outsource completely and ignore; and what you out source and audit.

Accounting - including billing, is normally something you should out source and audit. Let someone else worry about all the hard and weird rules. However you need to audit it because if you do not someone corrupt will steal your money and you are still required to pay whoever you owe money after that happens - this is one way your company can go bankrupt.

Re: Problems with homemade billing systems

#34

Post by lowercased »

Why do I have the feeling that many people starting projects like this get in to situations where functionality is identified and they're beat down with "YAGNI!"? I've been in situations where 'build v buy' comes up - accounting, inventory, and similar domains. Identifying "hey, we need to keep XYZ data to allow for future reporting..." has been met with chants of "YAGNI" from people blind to the complexities.

It's just one of the things that might lead me to opt for 'buy' in 'build v buy', but... it's hard to trust the sales people involved in the process as well. And... taking the time to do real and full analysis... is time people often don't want to pay for.

And... once you're "in" to a COTS system... you're almost never leaving. The companies know that, the salesfolks know that, and have a lot of incentive to handwave away concerns, or just outright lie. Once you discover the lies... it's likely too late to switch.

Re: Problems with homemade billing systems

#35

Post by re-thc »

specialp wrote: post #16
542458 wrote: 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…

Well one thing an OTS solution accomplishes is it makes costs and capabilities very clear to product and marketing. When you have an internal team doing something bespoke to your organization it is viewed as much more malleable. If the third party solution cannot support the billing system devised, or will support it for a large cost, companies are more likely to choose things that are more in the box.

> Well one thing an OTS solution accomplishes is it makes costs and capabilities very clear to product and marketing.

It gives that illusion. The reality is not so clear cut. There are lots of nuances to a capability that's not just a box check. It could be half-done, i.e. certain bugs in certain scenarios. It could be slow, unreliable or something else altogether.

There's also: https://www.businessinsider.com/former-vp-claims-salesforce-...

Re: Problems with homemade billing systems

#37

Post by re-thc »

calvinmorrison wrote: post #25
brianmcc wrote: post #18

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…

Interestingly, 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

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

Re: Problems with homemade billing systems

#38

Post by [deleted] »

542458 wrote: 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…

[deleted]

Re: Problems with homemade billing systems

#39

Post by wredue »

6510 wrote: post #26
vidarh wrote: post #13

I've built several billing systems and managed a team that built a much larger one, and it's not that hard, but it does require an attitude and attention to detail that a lot of people lack. 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 pos…

> #3, maintaining old pricing I copy the entire product into the order. The thing one buys should be the thing on the screen when the decision is made. Poor pictures, description with typos, wrong categories, old/wrong pricing etc

This approach is generally okay. It at least keep your mandatory data for audit around.

One issue with it is that it often ends up forcing you to build out a lot of backward compatibility into your audit system as things change.

Re: Problems with homemade billing systems

#40

Post by cjonas »

specialp wrote: post #16
542458 wrote: 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…

Well one thing an OTS solution accomplishes is it makes costs and capabilities very clear to product and marketing. When you have an internal team doing something bespoke to your organization it is viewed as much more malleable. If the third party solution cannot support the billing system devised, or will support it for a large cost, companies are more likely to choose things that are more in the box.

Except with many of these enterprise solutions (SAP, Netsuite, Salesforce) most companies will still need to pay consultants 300 dollars an hour to configure and maintain the application. These costs often exceed the license cost itself.

Bottom line, complexity is expense regardless if you build or buy. Companies need to factor the systems and operations impact of complicated pricing and billing models into the decision making process.

Post reply on HN