Hacker News Reader

Comment by 542458 | Hacker News Reader

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 guarantee that your third party solution would be able to support those? At least if it’s in-house you can implement the needed functionality eventually - if it’s third-party it might just be flat-out impossible.

View on HN

Sometimes the fact that you can't change it is a great feature. Obviously if it's missing a critical feature, then you are screwed, but often these requests for customization are made because it seems like they are quick and cheap to make and it will be automated and free after a one-time cost. However, having a whole team of engineers run your billing department is a lot more expensive than hiring someone in finance ops who can do a manual refund or spend an extra 5 minutes every quarter dealing with anniversary billing. Especially if you are B2B, you are going to run into that huge client that wants to be billed net 37 on the lunar calendar, and it's better to get someone in finance to send invoices if necessary each week than to calculate moon phases in your product.

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

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.

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.

That is not the case in practice. Those AAA vendors will ask you, the customer, for all the domain knowledge in a very expensive 'configuration project', and shuffle many of your specifications into a bespoke 'customization and integration project'.

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.

>how would you have any guarantee that your third party solution would be able to support those...

You could say the same thing about literally any 3rd party software or service you purchase. "Why use cloud services to do anything?" etc.

Sure this thinking will hold for some things, but chances are that for something as standard as billing you're not going to be implementing some revolutionary feature that gets you more customers. On the other hand, if you mess up billing because you rolled your own system that doesn't have many standard options that a mature OTS system would offer it can lose you potential customers, because for months at a time you're stuck building the most mundane and standard things like an annual plan that could be used to better appeal to buyers.

Survey the main OTS options and see what they can do. It will probably give some ideas like "Oh yeah annual plans, we'll probably want them at some point". At the very least you do this at the outset when you're small. Worry about complex billing requirements that won't be part of vanilla options in most OTS systems once you're big enough & complex enough to require them. Otherwise you're worrying about a Maserati problem.

>how would you have any guarantee that your third party solution would be able to support those...

You could say the same thing about literally any 3rd party software or service you purchase. "Why use cloud services to do anything?" etc.

For billing, a one of the most standard things ever for a business, you simply take a small amount of time to survey the OTS options and compare features. Any you know what? There's an excellent chance that buy actually getting a comprehensive look at features offered by such options you will learn about the types of things you will absolutely want to do in the future. Things that, in retrospect, seem like obvious oversights, such as an annual plan. You'll see features like that in your survey and say to yourself "Oh, yeah, that's something we may definitely want in the future, lets put that on our requirement list for a final choice."

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

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

Don't forget the money sinks that are any attempts to implement something differing with SAP or other big ERP systems.

You delivered extra value for customers (making you more competetive) thanks to some particular ability of your previous (even manual) billing rules? Kiss them bye bye.

That is not how any of this works. SAP is already sold to the C-suite on the basis of very fancy powerpoints and sales pitches before anyone in the enterprise can do a gap analysis. I have no experience with Oracle Finance, but I suspect the process will be the same.

Sometimes unlimited choice is a vicious thing.

With the power to modify anything, people will make decisions and choices with serious consequences and benefits that may or may not be tangible, or worth the squeeze.

I’ve spent most of my career working in and around government, and poorly scoped or framed legislation costs billions because it drives customization and development. The business and engineering impacts of those decisions are often not appreciated.

If you work for a corporation, and you have a off the shelf billing system that fundamentally does what is needed… you have a chance of using ROI or some other metric to save the (expensive, hard dollar) customization for when there is real value.

The other thing is that sometimes these custom systems create customer problems in the name of “helping”. I’ve had many times where some legacy SKU or billing model, left in place to make my life easier instead made things much much more difficult down the line.

Indeed. Very often organisations tend towards buying solutions without appropriately gauging the situation. One easy example from IT is buying servers vs renting them, but fortunately it seems that IT people have found the, for some uncomfortable, balance of "it always depends", and the analysis might turn multifaceted pretty quickly.

I also feel that people often discount the cost of up top decisions that people below don't like.

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.

Many of the OTS solutions in this area only cover the most obvious or common requirements. Anything advanced or specific comes with a very hefty bespoke project.

Reply on news.ycombinator.com