Fintech startups are the promise of change. The promise of going away from the stereotypical banks with their clerks behind glass walls. There are few distinctions that stark, however, as the innovation imperative. Many companies in finance realized, we can be doing everything more efficiently than before. Faster, on-demand, with nearly instant transfers, the future is meant to be user-friendly.
That’s what our client set out to do; not in a traditional way, though. Our American client decided to create a financial product to manage finances while also educating users on e.g., the value of money. The mission started more than a few years ago; and nowadays the company already has an established user base that counts millions, with many innovative features in their portfolio and more to come.
When an organization builds an innovative product, it’s easy to forget about the maintenance. When you are focused on creating value and building new cutting-edge products, it’s all too easy to lose sight of some technical aspects.
That's why the fact that the company already existed and worked on developing new products for a bit before we started our work with them is quite relevant here.
Our client approached us because they wanted us to help them with resolving their technical debt, scaling up their engineering teams, and building new features to accelerate their competitive advantage.
They needed us to help them with effective upscaling of their development teams to introduce new features, take advantage of the dynamic growth, and put the new funding, that the company had received, to clever use.
Our client experienced shortage of available IT experts. They were looking for software engineers specialized in certain technologies, but recruitment process was taking too long, and they were not many candidates on the market that met their expectations.
In a matter of three months, we managed to deploy four full-stack scrum teams with a total of 40 members, including Back-end, Mobile (iOS/Swift & Android/Kotlin), and Quality Assurance engineers along with a supporting team of Business Analysts, and Project Managers.
The back-end is the core and the heart of every application. In the case of our Fintech client, when we started, we already had some solid foundations. The fact that our client chose Node.js as the core technology was a great move. It perfectly fit their business goals and product’s requirements. However, the code needed improvements and updates. We started by bringing it up to date, our development team refactored the existing code and significantly reduced the technical debt. To make the core, the back-end, more fault-proof, we secured it against failures of external vendors.
Our client was using an external tool as a database. They wanted to gain more visibility into their operations by analyzing financial data for card transactions. There were two issues – the file with the data was quite large (we are talking about hundreds of megabytes and growing), and it was in a custom format. Our goal was to make the file available for an analysis and convert it back to the same custom format, to then upload everything back to the original database. This was not an easy task.
To design the workflow, and to have it run efficiently, and quickly, was no small feat. Luckily, Node.js has an API that made our work much easier. Streams made our work faster, and easier, which was crucial because we started from nothing.
The tool was relatively easy to create because we used the Node.js streams API to simplify our work, and to make it all execute faster. Streams are not that much different than, let’s say… arrays. The difference is, they are not available at once. Instead, chunks of data are available to us in sequence. This way, we can process files that are bigger than the amount of memory available.
On top of that, the model of concurrency of Node.js further made it easier to carry out our work. The way that single-threaded Node.js works (almost) like it’s multi-threaded is thanks to “Promises”. Let’s say you are in the middle of work, and want to make tea.
The non-promise way is: imagine instead of going back to work each time, you waited for two minutes standing there, doing nothing waiting for the water to boil then the tea to steep. By doing something in the background, you could say you have done the work of two people.
Going back, promises let you effortlessly design asynchronous apps much more easily, than in the case of different languages. If we had to work with C# or Java, we might have had more control over the implementation of our solution, though we would have to spend much more time designing it all. In the case of Java and C#, designing solutions that execute asynchronously is at times, a challenge. In JavaScript, it’s smooth sailing without major gotchas.
Of course, we also leveraged one of the biggest pros of the whole JavaScript ecosystem – the number of available packages. We could have implemented all of the logic ourselves, however, there was no reason for it – we installed whatever we needed, and took it from there. Of course, it’s always worth mentioning that, each introduced piece of 3rd party code is a potential security issue, so of course we did our due diligence on each package we introduced, and we didn’t overdo it.
In a project of a decent size, TypeScript is a saviour. Thanks to annotations in editors that pertain to what type of data we can use in each spot; developers create software much easier and faster.
Previously, without any help from editors, programming was more complex and time-consuming: the only help one had was internal documentation (that often did not exist) or variable names (which is not very helpful). You had to refer to the original code. Why work yourself if a machine can do everything for you? TypeScript can let you know what to use, where and when, on its own.
Businesses love adopting serverless functions (e.g., Lambdas). One only pays for the real usage, and pays by the second, so there is no overpaying or wasting resources, such as electricity for your servers. Another great aspect is the ability to deploy your functions around the globe. Higher latency is an aspect that is easy to eliminate, and at the same time, it is one that will hurt you a lot.
Back to the Node. Why are we mentioning it here? Node.js works great in the environment of Lambdas. We already covered this before on our blog – JavaScript & TypeScript functions work well in a constrained environment of serverless functions such as AWS Lambdas or Azure Functions. The cold start, which is the bane of existence of many cloud developers, is quite quick, while the code is superbly optimized – after all Node.js runs on the V8 engine – the same engine that powers Chrome. Google will do everything to eke out whatever gas is left in the tank to make V8 faster than Mozilla’s JavaScript engine, SpiderMonkey.
We leveraged all these pros and deployed our new code to Lambdas. Thanks to that, the app felt smoother, with faster response times. We also never worried about a potential spike in visits that would make our back-end sluggish, and we drove costs down, because we did not have to manage any servers.
Native apps are somewhat, counterintuitively perhaps, what we went with to solve our client’s business challenges. This approach was there before we even started the work with the American fintech. It’s not without merit, too. A React Native or a Flutter app would have been a viable choice as well. Saving time on the development, while keeping high quality is always the right call. There are some issues, however.
Firstly, if you want to create a perfectly looking app, that behaves the way other native apps do, then you will need to use the native tools. Sure, Flutter or Xamarin gives you a wide array of built-in components to work with, though they are not authentic.
Natively writing apps, is how one creates the fastest, and the most efficient apps, that feel the most natural for users of the platform that their phones run on. Yes, it will take longer to create them; but it doesn’t always have to be that way. Airbnb showed that embracing the truly native way does not have to be all that time-consuming with their server-driven apps.
We have previously written on this blog that Full-Stack engineers and a Full-Stack approach is a great approach to building applications in general and went on and on about the business advantages. Yes, it is, though we can’t use it everywhere, and in all cases.
Firstly, code is just a tool to solve a problem. You may solve problems in multiple ways, that are equally valid. Let’s look at a simple example: you don’t have a car, and you need to get from point A to point B. You may walk there, take a bus, or ride a bike – each solution has its own pros and cons, and each one of us might choose a different way.
Writing apps in Swift or Kotlin means you will be able to overcome any issue you will meet. Sure, React Native does give you a way to go in, and write native modules, though it requires you not only to know JS/TS; you also need to understand Kotlin or Swift as well. It’s not impossible, though it is hard. If we chose the native way from the beginning, we always stay within one realm.
As aforementioned, the native way does not necessarily mean that we are moving slower, and even if the initial development might be slower, the long-term strategic benefit of developing native apps was clear for our client who largely operate on a B2C model. Why is the business model relevant here? Two reasons. Firstly, individual customers expect apps to “just work.” With cross-platform frameworks, there is always some overhead. Lastly, Jakob’s law applies. In short, it’s the expectation of others for products to work the same way across the board. “Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know.”
The work we are doing with our innovative client is a chance to be a part of a movement to raise a new generation of financially aware people. People, who would not be budged by the rising inflation of today, or by any other financial hardships.
Fintech start-ups are the innovative fast movers within the financial world. Their biggest advantage over bigger competitors is the speed with which they can move, and their flexibility. This naturally brings technical challenges. Not only do we have to create forward-looking solutions. We also must create them fast.
We know all of this because we already have some notable experience in working with fintechs. Apart from the American Fintech Unicorn we talked about here, we have also worked with other industry leaders, such as Luma Financial Technology, Moneytrans., Cryptix, PayU, and a few others.
On the other hand, our portfolio is much wider, and we had a chance to work with many legacy banks and financial services institutions to create in-house fintech products that helped them accelerate innovation and keep up with the smaller competitors. These include BNP Paribas, FIS, Santander, and Raiffeisen Bank.
Therefore, we can fit into your needs and business goals, no matter if you are a Fintech startup or Financial Services Giant. If you need to design and develop a digital product, do not hesitate to reach out to us.
.svg){kind=small}
