Pricing Software and Beyond: Build vs. Buy

Off-The-Shelf or Custom-Built Pricing Software Dilemma

During my decade-long tenure with the banking industry, I've held diverse roles encompassing project, product, program, and fintech management.  One pivotal question throughout my career that banks and lenders (including myself) have consistently grappled with is the (new) age-old “build vs. buy” dilemma. This was especially true when looking into pricing software development. 

If you, like many other lenders, are faced with a choice of building vs purchasing an off-the-shelf pricing analytics software, this blog post will help you understand the pros and cons of both and present them to your management and IT teams.

Below, I outline WHAT exactly the Build vs Buy dilemma is with a special lens on financials services software, WHY it’s becoming more and more relevant, PROS & CONS and other considerations between an internal build and a vendor software buy as well as some TIPS & TRICKS for scoring good vendors. My hope is that this gives you some food for thought on your decision to help choose the right path for your organization! 

The 3 Routes 

Inevitably when the “build vs buy” question arises, stakeholders have their preferences on which route they would like to take.  There are typically 3 camps that emerge.

1. Use a Vendor

There is Camp 1 – They are all for buying the software through a vendor – typically the primary proponent of this has worked with a vendor in the past, either at the current bank or a previous organization.  

2. Build In-House

Camp 2, which are the strong proponents of building this in-house.  There is a very real pride in being able to develop and launch successful in-house pricing software.  Most banks have made some sort of software development a key focus on their organization within the last decade.  Whether that is called digital transformation, digitization or insert any other trendy buzzword here.  The perception is we have invested so heavily in this space why wouldn’t we build in house. 

3. Undecided

Then there is the Camp 3 that is not so sure about either option or perhaps even about the meeting.  They have vacation plans set for next week and all that is on their mind is frozen drinks by the pool/ beach/fire – perhaps even in that order.  But for those who are still tuned into the meeting they are likely still attempting to weigh the options.  

So which camp has the correct approach (other than people heading off to vacation, of course)?  Well, let me hit you with the first cliché of the day (pending trademark) “it truly all depends”.  I know that answer is unsatisfying, but below I will explain to you why that answer is the case and help weigh pros and cons as well as offer some helpful tips and perspectives from my experience to help you out when faced with this dilemma.  

A Breakdown of the “Agile” Approach to Pricing Software

As banks and lenders have adopted a customer centric approach, they have also adopted an Agile mindset and some form of an Agile approach.  Banks and lenders tend to call this Agile approach a “hybrid” approach.  

While on paper this hybrid approach sounds nice as it aims to strike a balance with Agile principles and practices against the challenges and constraints that come with being a heavily matrixed/bureaucratic organization.  In practice the balance of a hybrid approach is exceptionally hard to achieve.  

Throughout my career I have only seen/heard of a few select pockets of organizations that are truly crushing it with this approach, and even fewer that are practicing full-fledged Agile.  These are by far and wide the exception to the rule – the majority consists of an agile-based mindset with rigid phase-based processes and constraints (inside the squad and/or outside) coupled with the lack of regular customer feedback.   Often these “squads” are not tied directly to an individual product and have defined priorities and objectives that do not come from customer feedback.  

What does this produce? MVP (Minimum Viable Product) or Legacy?

Imagine walking into a dealership and purchasing a new F-150 in cash.  On the day to take delivery, the dealership was kind enough to deliver it to your front doorstep.  As you sit outside gleefully awaiting your new method of transportation you hear wheels down the road rumbling on pavement.  Your ears perk up, your heart starts pounding, as it rounds the corner you realize that it was a false alarm.  It’s just someone on a skateboard – but wait, why is he decked out in Ford merchandise?? Before you can come to terms, he kickflips onto your driveway and hands you the skateboard, as he exclaims “thank you for your purchase here is your new F-150!”  You can’t even snap back into reality before he leaves.  

Rationalizing that this must be some sort of joke you call the dealership only to hear from the sales manager, as she mummers “Ford has adopted an Agile approach to vehicles and next month they will be releasing the F-150 bicycle, should I send the invoice to the same address?”  I think it goes without saying how even a rational person would react to this situation.  

This is an extreme example, but I want to use it to ask this: “How come so many bank’s software products continue to operate to only evolve into skateboards and bikes?” The answer comes down to an Agile mindset without a true Agile approach.  MVP this is another common buzzword thrown around in today’s organizations it stands for Minimum Viable Product.  In other words, it’s an acceptable product, not necessarily good and definitely not great.  Kind of like getting C’s throughout college – its acceptable (enough) and it gets the goal accomplished.  

The problem is not that a bank has only launched an acceptable product into the market; the problem is that the bank has failed to adopt an agile approach in continuing to refine, integrate and build the product into a great product.  The squad came in built out a decent MVP (Minimum Viable Product) and then left to work on another product or area within the organization as priorities shifted.  Further making matters worse is that when the squad leaves, so too does the maintenance, support and knowledge behind the build.  Meaning that this MVP is operating with known bugs/issues that can’t get enough priority to be fixed (barring a complete break) or in some cases crucial knowledge is lost regarding the build to help support fixes.  

All this to say, that a well-intentioned MVP from 5+ years ago has long become a legacy product that remains relatively untouched.  Meaning that some banks and lenders have skateboards and bicycles (some with loose bolts and worn bearings) sitting in the market while best in class competitors are operating on well-maintained racecars – and yes, maybe even actual F-150s.

Since we’re well into car analogies, how about we wrap this section up with one?  At the end of the day the hybrid Agile approach and hybrid vehicles are all about 2 things: 

• Compromise

• Practicality

While full-fledged Agile gives you the robustness and reliability of a gas-guzzling, naturally aspirated V8, coupled with the acceleration, agility, and efficiency of a Tesla Dual motor, you get the best of both worlds, which allows you to reach your full potential.  This is exactly what you should be looking to get if you decide to go with either a buy or build approach.  

You will need a software vendor or an internal team that is not only able to launch a product with agility but continue to reiterate, improve, and maintain the product throughout the lifecycle relatively unconstrained.  

Competing Priorities: Customer Facing Software vs Internal/Business Software

If you have been in an organization for at least a couple of years, then you have surely noticed that some types of products/software seem to get all the love while others tend to be pushed down the road to be reviewed “at a later date”.   You soon begin to realize that a later date means the stars need to align and you may also need some singing from the heavens to get a build or much needed enhancements made to your product – and if there is a workaround available you might as well kiss that hope good-bye.

If you haven’t figured it out by now, I’m speaking towards the difference in priority given to Customer Facing Software (Mobile Apps, Loan Applications, Websites, etc.) vs. Internal/Business software think Loan Origination Systems (LOS), HR systems and platforms, pricing software, etc.  Customer Facing systems tend to be treated as the golden child while internal systems are shoved under the stairs dreaming of one day attending Hogwarts.  

And you can’t entirely fault the prioritization, as many banks and lenders have moved towards a customer obsessed model and customers are what ultimately drive a banks success. Therefore, putting resources towards making customers experience better is not a poor decision.  You want your customers to be able to directly touch and experience the improvements that have been made.  It helps drive loyalty and deepen relationships.  It’s a fair point, so the question then becomes “where does that leave the other products, and especially internal software? And how can they too make necessary improvements to drive meaningful change that indirectly impacts customers?”

Unloved products and software have two choices – the one has already been covered in waiting for the stars to align, heaven singing etc.  The other is to start exploring buying an off-the-shelf software solution.  Exploring the market and looking for the right vendor to support you.  I’m talking about getting out from under the stairs, marching down to platform 9 ¾ quarters and finding your Hogwarts.  

(side note – it took every ounce of my self-control to not turn that into another car analogy, you’re welcome 😊)

Pros & Cons - Buying vs. Building Pricing Software

This is in no way meant to be the end all be all list of pros and cons, but is it meant to be taken as considerations – you may be a part of an organization where something on the con list is actually on the pro list and vice versa. Conversely with software vendors it can absolutely be the same way. Nevertheless, it’s important to look at it objectively to figure out where each of these falls.  I put these together based on my typical experience and I also listed the flipside of every item.