Earnix Blog > Pricing

Pricing Software and Beyond: Build vs. Buy

Sean Johnson

October 1, 2023

  • Pricing

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.


Time to make a selection: Build vs. Buy

If your bank/product is operating on true agility with guaranteed future support for iterations, true expertise within the team of building/developing software and proper attention to governance – essentially if you check all those boxes on the internal build and mitigate or even flip those cons to pros – I’m saying build it internally!  Without question.  

However, if those cons are starting to heavily outweigh the pros or even if they are fairly close, I would recommend at the very least exploring a vendor-built solution.   A great vendor can mitigate those cons and even flip them to pros to deliver a truly exceptional product – but how do you know it will be a great vendor? 

How to ensure you are selecting the right vendor for the right off-the-shelf pricing analytics software?

In my experience it all comes down to vetting. You want to ensure that you understand the vendor market and vet as may relevant vendors as possible.  

Unsure of the market? Other than the obvious online/google/ChatGPT – Conferences can be an excellent place to meet a wide array of vendors and hold some initial conversations.  Also, connections made here with other lenders or at industry roundtables can be great resources for asking for recommendations and experiences.

RFP (Request for Proposal):

An RFP is a tool that can be leveraged by a bank or lender to compare and contrast different vendors for a particular solution.  This can help showcase strengths and weaknesses across multiple vendors and allow you to get a clearer picture of their products and the overall market.  

Be sure to pay attention and take note of promises made in sales pitches to ensure that during demos these promises are delivered upon.  Now is the time to ask difficult questions before commitment vs when it is too late.  

POC (Proof of Concept):

A proof of concept is an excellent tool to understanding the value vendors can provide.  It also gives you an opportunity to explore the product you or your customers will be using prior to going live.  This helps to get a good sense of if this solution will meet your needs and what sort of value it will provide.  There tends to be a small fee associated with running a POC, but trust that the fee is substantially less than blindly signing on and being stuck with a product that doesn’t deliver value.

Closing Thoughts: 

A question I have been often asked since leaving a bank for a software fintech is “Why did you make the switch?” And apart from a change of pace my number 1 answer is that I generally researched and scoped the company as I would any Fintech vendor.  I visited their website, I looked at their competitors, I researched their investors and talked to industry contacts that directly worked with Earnix.  What I was able to glean from this research is that they are a strong company, with top notch expertise, that delivers a solid product, built, and enhanced through full-fledged agile.  I simply couldn’t find a reason not to join.

If you’re in the market for a pricing solution do not hesitate to reach out to me – I’m more than willing to share with you not only how I vetted Earnix but how I have seen my research come to fruition in working with banking and lending clients on a daily basis.   At the end of the day there are some great and talented people who work here that bring this product to life – some would almost want to call it wizardly (sorry, that was a terrible connection to earlier, but it feels fitting).

Share article:

Sean Johnson

Customer Success Manager, Earnix

About the author: