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

21–30 of 105 posts

Re: Problems with homemade billing systems

#21

Post by agos »

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…

see also: e-commerce systems. Hard to build, a lot of work, but way better than any 3rd party

Re: Problems with homemade billing systems

#23

Post by jasode »

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 :

(1) customizations via extra programming or extra add-ons.

(2) eliminate that software as a viable choice and move on to the next OTS software for evaluation

> At least if it’s in-house you can implement the needed functionality eventually -

The vast majority of Fortune 1000 businesses replaced their "homegrown" accounting and payroll systems they built in the 1960s/1970s/1980s -- with COTS ERP systems like Oracle Financials and SAP R/3 because their internal IT teams never got around to the "eventually" option.

There's an anecdote (I think from the book "I'm Feeling Lucky") about a Google's early startup years where an employee said they "needed to buy SAP" for accounting. The co-founder Sergei Brin was dismissive, "why do we need to buy that when our programmers can build it?" 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. About 20 years later, they migrated from Oracle to SAP.

Re: Problems with homemade billing systems

#24

Post by dagw »

acutesoftware wrote: post #15
yugarinn wrote: post #10

Earlier quoted context omitted.

My experience is that the scope is never kept narrow, which is exactly the same that the author is describing.

Well, you can - you can have a policy that forces payments from a select group. Some users will complain when "No, you cant pay with 2 chickens every 3rd full moon", but that is too bad.

Of course you then have to be willing to turn down money/customers. As someone who has worked for quite large traditional companies, we've ended up not buying from certain companies because they couldn't invoice us like we wanted to be invoiced.

Re: Problems with homemade billing systems

#25

Post by calvinmorrison »

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

Re: Problems with homemade billing systems

#26

Post by 6510 »

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

Re: Problems with homemade billing systems

#28

Post by vidarh »

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

Yeah, that can be a good approach. Including all the data defining the old product in an unchanging way was one of the sticking points that led to the creation of my team at Yahoo. The US team didn't think twice about changing invoice templates for examples, while the European finance teams broke out in hives at the thought of anything changing on already issued orders, much less invoices. I spent three years holding the fort to ensure the US team didn't take over invoice processing on our behalf until they could guarantee at least the invoices were unchanging...

Re: Problems with homemade billing systems

#30

Post by 6510 »

dagw wrote: post #24
acutesoftware wrote: post #15

Earlier quoted context omitted.

Well, you can - you can have a policy that forces payments from a select group. Some users will complain when "No, you cant pay with 2 chickens every 3rd full moon", but that is too bad.

Of course you then have to be willing to turn down money/customers. As someone who has worked for quite large traditional companies, we've ended up not buying from certain companies because they couldn't invoice us like we wanted to be invoiced.

And miss out on all the fun with buyer-created invoices?
Post reply on HN