3 Questions Banks Need to Ask When Building vs. Buying


This is the fundamental question of the “cloud” era. Do I build something from scratch in order to get the most complete and “fit for purpose” tool? Or do I buy something knowing that it may not be 100% of what I need, but with benefits that outweigh the gaps? As I wrote in an earlier post, when properly considered through the lens of technical debt, the answer should be “both”.

There is enormous value in shifting technical debt to the platform, leaving you with more capital to specialize in your needs. Increasingly, the general response is, “let’s just build all of it ourselves” instead of going with a platform. This attitude is based on a foundation of poor assumptions and rationalizations that look right, but significantly increase the risk of technical debt load.

There are generally three main arguments that circulate amongst developers when dealing with platform adoption: Trust, Control, and Suspension of Disbelief (SoD):

  1. What happens if the vendor goes away/fails/has a bug/something goes wrong? (Trust)
  2. You will lock us in and we won’t be able to switch if we want to? (Control)
  3. We can build the same thing/better thing/our thing just as well and really fast. (SoD)

Trust

Building a full-stack yourself means you have to deal with all the bells and whistles, integrations, and ultimately the issues that arise from your software. There is NO software that is perfect. That means that even if you build it yourself, you can still have issues and defects. When you move to a platform, what you are putting in place is a partnership that will help you deal with issues, instead of having to rely 100% on internal resources.

If your technical debt load is high, it becomes more likely that those issues may never be resolved. The balance you need to weigh is “do you trust your vendor to be there for you to resolve them”? The simple litmus for this is longevity. There is significant risk in partnering with a new company or an unknown, versus an organization that has been in business for many years. This risk is no different and no less impactful than losing your key internal developer. Both scenarios need to be carefully considered and the underlying exposure to bad debt carefully evaluated.

Control

Vendor lock-in is most often cited as the reason for not using a third-party technology. This is particularly true with a platform as they are acting as a core internal component of a solution. They key is to find a platform that offers you the best functional outcome with the lowest friction of movement. The more “black box” a solution is, the harder it is going to be to move off it because you have ceded all the control to the platform provider. That lack of visibility means that recreating the functionality is significantly more difficult.

A fully viable platform has “just enough” openness to allow you to migrate easily to other providers (even home-grown ones). It also offers the advantage of being a comprehensive platform with options you cannot get elsewhere. This idea of the “whole product” approach to platforms allow you to realize value immediately from the platform without complex integration or development, and then grow into it over time by pushing the boundaries of its capabilities. A truly open platform will allow the best of both worlds without forcing you in one direction or the other.

Suspension of Disbelief

The most common answer we hear in the market when asked about the first wrong assumption made when planning to build you own solution, is time and effort estimation. We see in the market, that developers lean towards the “build it” model with consistent regularity. They focus on the internals, the code, the functions and features, and generally ignore things like time. That last consideration is almost always wrong, both in real dollars, and level of effort.

Building integration points is also a constant struggle because it isn’t just your software that has to work right. You are relying on other providers to make sure they do not make changes or create unanticipated issues that cause your integrations to break. A platform provider has to do that as well, and the outcome is that your platform continues to work the way you expect because they’ve accounted for the underlying changes. Just like you wouldn’t try and build a database, or an identity management solution from scratch, a platform keeps ahead of the curve by anticipating and mitigating changes.

Platformification

A platform provider is focused on one thing: the functionality the platform provides. As a platform provider, Avoka builds the System of Engagement for customer acquisition. That means we don’t waste time trying to build front-ends to fit every possible scenario (we let the customer’s developers do that). It also means we don’t build Systems of Record (we let others do that). What we focus on is eliminating the challenge of getting those things to work together by building the “glue” that simplifies and tightens the integrations of those solutions. We free developers to work on the parts that are most important to the process by simplifying the stuff that no one wants to do anyway.

Chris Harrold
Chris Harrold

Chris is the Director of Developer Programs at Avoka.