What we’ve learned from 4 years of building fintechs
Four years doesn’t sound like much but in the rapidly changing world of fintech it feels like forever. It’s hard to say for sure when the phenomenon started.
While the earliest signs popped up at the turn of the century with Paypal, neobanks didn’t form until 2016. That was only five years ago.
Last week, during an all-engineers catch up with my preciouses (yes, that is what I call my peers in applied engineering) I thought it would be fun to swap stories and reflect over what each of us took from our time building fintechs.
The first product ever created here was 11:FS Pulse and, lucky for us, the engineer that built it from scratch is still here. It’s funny to watch Martin (Engineering Manager in Pulse at 11:FS) recall those times. Building Pulse has taught him a few interesting things:
Not to be afraid of using third-party services for things you don't have time/knowledge to build at the start.
Content is king. All the clever code in the world doesn't matter if users aren't interested in your product.
Not to feel guilty for using 'old' or 'uncool' tech. If you can justify your decisions and it doesn't affect the user experience, it's fine. Not every app or platform should live on the bleeding edge.
What we learned is that for some dream products you don’t need an army of tech people - one magic developer might be enough.
Building separate fintech products that help the consumer is fun and somehow simple. Simple compared with re-architecting banking infrastructure. One of the most quoted reasons for the birth of fintechs is the old and frail underlying systems used by traditional finance institutions.
Building separate fintech products that help the consumer is fun and somehow simple.
The developers in the 11:FS Foundry side of the business know it too well. Their learnings are the rawest. Jamie (Lead Engineer in Foundry at 11:FS) is right, the size of the codebase in a project like this needs to be closely watched, not go out of control with complexity. Starting from scratch gives so much freedom. Maybe too much. You have to choose your tech very carefully and be strict about evolutionary architecture. Nobody wants to build another system that doesn’t have the flexibility to evolve.
When you trade in uncharted territory you won’t get it all right the first time and rectifying costs are considerable. Sadly, there’s not a lot you can do about this. Focus is incredibly important. Alex (Senior Engineer in Foundry at 11:FS) points out that Foundry has the potential to do a heck of a lot, but has found that the most progress has been in focused, tangible product features.
One of the biggest things I've learned is that in-house software building is not the same as consultancy building. It isn’t easier or harder, doesn’t influence how much you care and it isn’t less rewarding. It’s just different and what you make it. Your client and the relationship you have with them matters the most. Tech builds are not sales pitches. You’re far more embedded in the client organisation and work more closely. You might be building someone else’s dream, but if you don’t dream it with them, you definitely missed the point.
Tech builds in a consultancy involve being more human and less geeky. As Jason (Lead Kotlin Engineer in Consulting & Research at 11:FS) puts it, you need to learn how to translate purely tech tasks into intelligible simple language, so that everyone in the team can understand the importance (or lack of) of what you’re doing. The people you choose to work on the project are of immense importance. David (Senior Engineer in Consulting & Research at 11:FS) makes a very good point here. As uncomfortable as it is to admit it, as you build this product, you know you will not suffer the long-term consequences. Choosing the people that will fight the good fight and put in place processes that protect the integrity of the project is key.
Tech builds in a consultancy involve being more human and less geeky.
You have less overpowering control. We all know that for in-house builds, if you need something, you can just muscle it in. But with consultancy you have a duty to explain it until it’s understood. As Jason again hits the nail on the head, you’re like an aunt to a child. You can give advice but don’t have the authority of a parent (I like to think I am a cool aunt).
The way you do compliance and build audits is different. As Calum (Lead Engineer in Consulting & Research at 11:FS) correctly identifies there are some layers of complexity: how much information can you use when presenting your product in a pitch, storing data in other jurisdictions, having your’s and your clients’ compliance team work together. Compliance, logistics and IP is all about trust and integrity.
When I asked the question about our learnings in the meeting, I expected a full-blown geeky talk about technical details. How close-minded of me! What we learned in these four years is far deeper than that. Tech is important and even more so are the processes that surround it. The value of a brilliant idea lies in the execution. External, uncontrollable factors (like a pandemic) can slow you down, but not stop you.
