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

51–60 of 105 posts

Re: Problems with homemade billing systems

#51

Post by cvccvroomvroom »

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…

Exactly. You really need experts in entity relationship data modeling (typically in Oracle DBMS), data hygiene, and codifying business rules. This isn't something web developers should generally take on. Software involving money should consider approximating the formality of engineering approaches: waterfall development model, formal verification, and extensive unit and integration testing. There are hidden costs that edge up TCO for DIY. It's possible COTS maybe very expensive or incapable of being customized sufficiently to meet the needs of the particular application, but DIY should generally be the last resort when no other viable solution exists.

Re: Problems with homemade billing systems

#53

Post by kayodelycaon »

cjonas wrote: post #40
specialp wrote: post #16

Earlier quoted context omitted.

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

The absolute cost isn't important here. What's important is that cost is now explicitly on the balance sheet were someone can see it. If you have an in-house system, that team is treated as an infinite supply of features for no apparent cost. (Ask me how I know.)

And as a developer, I love being able to hand certain people over to vendors who are used to dealing with those certain people. Hell, if we picked the right system, those vendors will have useful domain knowledge I don't have.

Re: Problems with homemade billing systems

#56

Post by scott_w »

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…

We migrated to Zuora and, while there are limitations, they’re far less than your own limitations. Honestly, if you can’t model it in Zuora, what you can do is likely close enough that it’s not worth the 100x extra effort to build your own system.

Re: Problems with homemade billing systems

#57

Post by danenania »

ftxbro wrote: post #12

This is an ad by a company that sells billing systems. This is what ads look like now.

A lot of useful content gets produced by companies as a form of marketing. Just like independent devs are often blogging with the goal of getting consulting gigs or advancing their careers. There's a lot of garbage too, but if the content is good and reasonably objective, what's the problem?

Re: Problems with homemade billing systems

#58

Post by agentultra »

In my experience this happens frequently enough that there ought to be an article like this for every problem domain that software developers and executives under-estimate the complexity of.

I work on card transaction processing and it's absolutely more complicated than you can imagine looking at it from the outside. It's a vast, distributed peer-to-peer system where trust is built into liabilities outside of the network itself. You want to build a system that is correct with regards to some specification in order to protect peoples' money... but the problem is that there is no specification that enumerates every possible transaction state because while there are "typical" sequences of messages to handle, your system also has to handle unexpected sequences that can't be specified: there are no guarantees that systems on the other end are emitting properly formatted events let alone behaving as expected. Card payment handling systems have to have the ability to manually correct and adjust state by humans; reconcile with external systems (because yay, payment systems in the US aren't based on instantaneous settlement until the roll-out of FedNow is complete), etc.

I've watched many businesses walk straight into, it's just X, how hard can it be? Only to watch their ARR shrink and stress levels rise when a project they thought would take a month turns into a year-long journey of discovery, reflection, and increased head-count.

Re: Problems with homemade billing systems

#59

Post by jabart »

When we launched in 2017, we went "in-house" with our billing. We found an open-source project and uses that for all billing as it had a recurring option and a billing portal. Fast forward a number of years, we now sync invoice data in the app and have a tiny billing portal there. We can still adjust invoices, keep old pricing, setup new pricing, auto-bill, check balances to see if a customer hasn't paid yet. Total Lines of Code here are like under 2000 for this integration and it's great. Also zero vendor lock in as well. Just another way to approach a billing system.

Re: Problems with homemade billing systems

#60

Post by MightyBuzzard »

6510 wrote: post #9
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…

HAHAHA, my estimate was 2 weeks. This was 6 months ago. It is now a marvel of engineering with most of the 100 000 edge cases covered. You should read that as: not battle tested on (insane) users. (I'm so looking forwards to that) I estimate 2 years to completely finish it, give or take a decade or two.

[dead]
Post reply on HN