Buy, Build Or Both?

When confronted with the need to develop new digital solutions for our customers, we are frequently presented with two options: Buy a solution off-the-shelf, or build something bespoke with either in-house development resources or with the help of contractors. But is there another viable option?

In my previous job as Director of Digital Solutions at a large international financial institution, I had the opportunity to experience first-hand the pros and cons of the buy/build choice. I will start by saying that the mantra at that bank was frequently “why buy if we can build it ourselves?”.

I would joke with my team saying that if we were building a car, instead of a financial solution, it would take us years on end since we would start by planting rubber trees in the Amazon in order to make the tires in-house, as well as build our own steel mills for the body panels. As far-fetched as this sounds, it was not too far from reality, as we had developed our own software development tools, and programming platforms. Yes, we did all that in-house. Even our Core banking solution was custom made.

The primary benefit was evident: We could develop exactly what we wanted, the way we wanted. We owned the user experience end-to-end. But at what cost? Mainly, time and resources. Most of these projects would start with a series of user-centered design sessions, research with the multiple areas an departments involved with the solutions, followed by rapid prototyping, user testing, defining the MVP (minimum viable product) and finally development, of course, with some kind of in-house tool.

Building things had other benefits, as we could actually create completely new things in the market, things that would allow us to be on the leading edge of financial innovation, like a re-imagined money-movement solution that would shield the user from having to use banking jargon (ACH, Wire, P2P, 3PT, etc.) to execute multiple types of transactions without any banking knowledge. Or a simplified voice navigation solution that would make using the mobile app a lot easier for most customers, without having to deal with menus, buttons or command bars.

And while this proved to work well for some things, when it involved a larger effort, or something that already existed in the market and had customers used to a way of doing things (Bill Pay for example), developing something new got much more complicated. Very quickly. Yes, theoretically we could build our own version of Bill Pay or Account Aggregation, but the relationships with all the different payees, vendors, etc. made it practically unrealistic.

Last year I had the opportunity to join Simmons Bank as Chief Digital Officer, and found that things couldn’t be more different. Here most of the solutions were off-the-shelf products supplied by vendors. This created a different set of opportunities and challenges. On one hand, we could bring products, features and services to our customers much faster that building something from scratch, the solution would be already proven to work as expected and provide a good experience, but we were constrained to what the vendor had to offer, for better or for worse.

Fortunately, when deciding on a digital solution to deliver Mobile and Online banking to our customers, we chose a vendor that while providing a good platform as-is, it offered the opportunity to enrich its features and functionality with our own in-house solutions with the use of APIs. This opened a third door for us: Not just Buy or Build, but Both.

Starting out with a good standard solution, we were able to build our own middleware to enrich the functionality of the platform. And with a brilliant -albeit small- development team, we started a new journey.

After a few months of work, we were able to add custom Credit Card features to our digital banking by hosting our proprietary middleware in the cloud, achieving the benefits of buying and building at the same time.

This new approach has given us the opportunity to develop new functionality much faster by leveraging pre-existing components, and integrating them seamlessly with our in-house code in a cohesive experience for our customers, allowing us to differentiate our products and services from other financial institutions using the same base solution.

Of course, this third option has its own set of limitations, as we could only develop things in conjunction with the vendors, often requiring minor custom code to accommodate our requirements, but overall, I would say that this has been a great experience.

Choosing the right partners is critical. While some vendors would not allow for customization, in this day and age, if your vendor does not support building your own additions with the help of APIs, it may be a good idea to look elsewhere.

With so many FinTech’s providing niche solutions that are readily available, easy to integrate, and in many cases best-in-class, it would be detrimental not to take advantage of this. While most large financial institutions would prefer to do everything in-house, I firmly believe that with a good Buy + Build approach, mid-size FIs would be able to catch up much faster to their larger competitors with the help of FinTech’s, and eventually leapfrog them in the race to win the digital customer of today.