Banks are finally reconsidering the build versus buy equation

This week was the first time I've said the following words, with all seriousness, in a sombre, professional environment, surrounded by serious peers, when asked for a solution to a pressing issue: "

We could just build that ourselves,

These aren't words you throw around liberally in a professional setting, at all.

And, usually, this is the last response that any executive in any bank will typically give.

In a traditional world, the last thing you want to be doing is 'reinventing the wheel', especially if your organisation has spent the last few years developing best-in-class modular services, underpinned by zero trust environments, that can be easily augmented and extended with external best-in-class, proven software.

The underpinning thinking was: Buy, not build.

Buy, because you get (or can demand) a service level.
Buy, because it's their problem (i.e. the vendor's responsibility to maintain and manage) and not yours.
Buy, because it's non-core.

In Financial Services, you would often hear the phrase (or, often you're the one saying words to the effect of) "our primary business is credit risk management," implying that getting into the software development business is, with some exceptions, rarely a key focus.

If you've been around the block long enough, you'll have painful memories of having to hire a very expensive 'resource' to debug and fix some 1997 Excel spreadsheet-based nightmare that runs a critical function in some department that your team somehow inherited responsbility for.

That's usually where the nightmares of old came from. Maintenance.

Most technology teams are, I think it's fair to say, privately delighted that the days of "Dave from accounts just made this Visual Basic core banking system and now it runs the car leasing division" are now well behind us.

Building was often quite easy. Others were often incentivised to build. Managing, pen-testing, supporting, maintaining poorly built scripts and hacked-together apps - that was always an incredibly expensive pain.

Until now.

We're now in a world where if you can imagine it, it can be built, swiftly and reliably, by skilled engineers, orchestrating the likes of Claude Code, Codex and Gemini. What's more, it can be extended, upgraded and maintained to a much higher rate of confidence than before.

The key phrase is 'skilled engineers'.

In the hands of people who know what they're doing, this technology is changing the internal technology landscape rapidly. It's changing the focus, emphasis, circumstances and realities. The old rules still definitely stand (one might argue moreso): Test, test, and test again -- and, it's still your responsibility, even if "an LLM" developed some (or all) of the code.

"If you haven't seen it working, get one of your engineering colleagues to grab a $20 test account from any of the above (Claude Code is my preference but the others are great too) and have a play in a test environment. See what it can do!