Lesen Sie diesen Artikel auf Deutsch
Since the earliest days of enterprise technology, one question has been asked time and time again: “should we buy this in or are we better off building it ourselves?”
Build vs buy is a perennial discussion point, one with a narrative just as mutable as the technology it concerns. What was once a simple debate about the benefits of a pre-built solution against one developed in-house is now much more nuanced. From APIs to SDKs ( software development kits), and subscription models to maintenance plans, the question of whether to build or buy now requires a good deal more thought than it did even a decade ago.
Which factors specifically need to be considered, though? How do you ensure that you’re making the best choice when it comes to your future technology needs?
At Lendscape, we've helped many of our customers to evaluate their own tech next steps and created a range of custom solutions - underpinned by smart APIs , cross-platform support, and monthly software updates. As a result, we’ve developed a good understanding of the key questions that surround the topic of build vs buy.
With that in mind, here are the eight questions we think it’s critical to answer before deciding on whether to build or buy.
1. How do the costs stack up?
For many, this will be the only question that needs answering. While costs can be easy to quantify from a “buy” perspective, they can be much harder to pin down when it comes to in-house development. Planning, building, testing, and deployment are complex cycles, and a detailed understanding of each cost (including the significant potential for creep and delays) is essential. There are also the longer term cost considerations of maintaining the system - technically, functionally and from a risk and compliance perspective.
2. Are we tackling a problem that has already been solved?
As alluded to above, even the best-managed in-house builds can quickly spiral out of control. When that happens, it can expose your organisation to all kinds of issues – both financial and operational. The ever-expanding (and increasingly connected) nature of today’s technology ecosystems means that there’s usually a solution for most business needs already. Can yours be met without taking on those risks?
3. Can we guarantee that what we build will actually work?
One of the major benefits of commercial software is that the hard work around testing and QA has already been done. Better still, plenty of organisations have likely put it through its paces already, providing further scope for iteration and refinement. That’s not the case with internally-built solutions, which offer few guarantees about their ultimate performance.
4. What’s our exposure in terms of technical debt?
Short-term convenience can translate to long-term complexity. A key argument from engineering teams in favour of the “build” model is that they often find it easier to develop a product using the systems and languages they already know. The counter to this viewpoint is that – as needs change over time – a never-ending trail of functionality requests can lead to a huge amount of “technical debt”, i.e. remediation work and investment to keep the system fit for purpose, secure and compliant.
5. Can we deliver ongoing innovation?
Both software vendors and in-house teams are under perpetual pressure to respond to new demands and opportunities. This is standard fare for software vendors, thanks to API-led integration and partnerships, and continuous exposure to multiple clients with differing needs. However, staying on top of industry requirements and ongoing innovation can be an unfeasible – and unreasonable – challenge for in-house teams.
6. What kind of legacy will our in-house build create?
Innovation isn’t the only forward-looking issue to consider when you choose to build in-house. The team you have right now may be confident in their ability to handle upgrades and feature development requests, but their work will set the tone for years (and potentially decades) to come. How great is the risk that your future functionality could be hampered by irreversible decisions made now?
7. Do we have the right vendor?
Let’s say that you’ve chosen to buy. Now you need to know that the vendor you select can do what you need. Technology investment isn’t just about the product – it’s also about the knowledge and expertise that comes with it. Can the company you’re working with manage sophisticated challenges like fraud and risk management or regulation changes? Do they work with partners or support integrations that can help you achieve your current and future goals? Or will you be back to building something bespoke to fill those gaps?
As important as these seven questions are, I’d argue there’s one question that outweighs any of those above.
8. Is building this solution a core part of your business – and if not, what’s your motivation for doing so?
Is your core business commercial finance, or is it writing software for commercial finance? The stark reality is that most banks and lenders don’t moonlight as software development companies. Tempting though it can be to create something bespoke to meet a specific need, the likelihood is that a solution already exists. No matter how unique a challenge or service may feel in isolation, the right technology partner - with the flexibility to offer access to the right of partners, services and tools - can almost certainly provide an answer.
In closing, every organisation needs to make its own decisions about whether to build or buy. As we have seen, there is much to consider, and this is not a decision to be taken hastily. Whatever direction is chosen, it will be to the long-term benefit or detriment of the organisation. Choose wisely.
Article written by:
Iain Gomersall