Close
The ‘buy vs build’ debate is decades-old. Is it better to purchase off-the-shelf solutions or to develop custom solutions? It’s an argument that crosses many industries, but software development is perhaps its most active sandbox for analysis and discussion.
Regardless of which camp you fall into, I believe the debate itself is often put forward in overly simplistic and dogmatic terms. It’s as if one paradigm, done right, is the key that opens all locks.
In digital banking, blindly adopting a binary view of buy vs build is hazardous, and misunderstanding the nuances of the differences may lead to making ignorant decisions.
The way every factory doesn’t build their own electricity plants anymore, companies shouldn’t spend time and money building something that doesn’t provide any differentiation to them, but instead, buy it, or even better – consume it as a service.
Modern technologies allow us to make micro-level choices. Instead of deciding on ‘buy vs build’ for the entire system or an application, we could do it for individual parts. There is even a term for this, called ‘Composable Enterprises’.
At Mambu (the company I worked for previously), we were the first to identify and apply this concept in banking. We called it Composable Banking.
The decision whether to ‘build or buy’ should be made on each solution capability. Many criteria can help decide whether to buy or build, but the key ones are the following:
Our experience in today’s Digital Banking technology shows that most vendors are still trying to answer this question in the same binary way, i.e. are we helping banks to buy or build? When I founded Plumery, we decided to change that paradigm. We call this principle –
‘Buy for parity, build for competitive edge’.
Whenever a vendor is over-focussed on the completeness of the solution and providing as much out-of-the-box as possible, especially on the front-end side, the tradeoff is significant.
Businesses (banks in this case) are losing a great deal of flexibility and the ability to differentiate themselves, particularly on the UI/UX (front-end) side of the solution, where differentiation is essential. An excellent user interface is a storefront to any bank today, and it should reflect the brand and the values of that bank. Imagine the world if every brand would look the same. How would one business separate itself from the next?
This is almost certainly one of the key reasons why none of the top digital-first banks in the world uses traditional off-the-shelf digital banking platforms.
If you want a proposition that goes beyond the mediocre, you should take charge of defining and building it.
The next question is how best to do so in the most capital-effective manner possible. After all, while many banks have grand ambition, few banks have massive resources. Hence, getting the best bang-for-buck is more critical now than ever.
In the case of Digital Banking, I believe the answer to this problem is a digital banking platform that provides the non-differentiating capabilities a bank needs and a pre-built Developer and Application Hosting Platform that addresses the most complex yet critical needs of a modern distributed architecture.
One that meets the strict security and compliance requirements of any typical financial company and enables developers in the bank to rapidly build new differentiating capabilities without spending time and money solving complex architecture challenges.
Visit our page to learn more about Plumery and how our Digital Success Fabric could help leverage build and buy to create delightful and differentiated customer experiences in banking and get started already now.
Share this post
The latest news, technologies, and resources from our team.
