Why FinTech Software Projects Fail
Interview with Alex Sukhenko, CTO Salsa Labs
Technical challenges differ at every stage of company development. Alex Sukhenko has wide experience working in startups and enterprises. We asked him about the challenges that he has observed in early-stage startups and in companies’ later stages. Below, his ideas regarding why problems arise, and how to avoid them, are outlined.
Building a platform from scratch
FinTech startups have to build their platform from scratch. They need to cover various aspects—onboarding, scheduling, monitoring, asynchronous work, etc. They use two-week iterations and in the best case what they deploy is used for the demo. They’re not building complex automated testing because so many things are done and changed quickly.
It takes a lot of time before they get something tangible that they may call a minimal viable product.
“But once you start to let people on it, all the stress cracks and weaknesses surface as real-life use cases are applied by customers using your services concurrently and at scale, defects that your testing was supposed to validate present themselves and you now need to plan to manage defects and adjustments in parallel to your never-ending list of enhancements.”
Alex says that in the early stages it’s better to release as quickly as possible, and then start beta testing and getting feedback about usability and functionality.
Reengineering a legacy platform
Over time, the platform becomes complex and problematic. It has monolithic architecture and two layers—the web application layer and the mobile application layer. Each application has a pool of services—sending emails, processing payments, asking for donations. Once a service encounters a problem, both applications are broken.
It’s difficult for the team to develop new features and keep the quality high, so they decide to stop R&D investment and focus on building a new platform that will replace the legacy one.
They plan to change the system architecture into microservices. They make a timeline and have two-weeks sprints. They expect to complete all the functionality in eight months and then migrate all their clients off the existing system within a year.
But they fail to do everything in time.
Alex believes that as the company starts to build a new application with similar functionality, they should first look at the challenges and problems that arose from the previous application’s architecture and decide how they can break it down into loosely coupled microservices.
Building a development team
The company decides that the software-development team should be divided according to their tasks—UI, API, QA, etc.
UI designers paint out static stuff, but when the API team does their work, the UI designers become completely confused about why the UI doesn’t work in the API exactly as they thought it should.
In this case, cross-functional teams work much better. Communication between designers, developers, and QAs is better established there. They can then quickly figure out what is being done wrong, and adjust it.
Moreover, Alex says that the architecture has a big influence on how the teams should be structured.
“Even Amazon, from what I know, is built internally on various services, and the teams focus on services and then those services interoperate.”
Deadlines are necessary. The sales team gets something in hand and can start selling it. However, each coin has two sides.
The development team wants to make a deadline, but the scope of work is too broad. As a result, they release a rough version with a limited set of features. Then they get customer feedback—some features don’t work, or don’t exist.
“Finding the right features, scope, and UX is key. Usually, you’re either doing not enough or the wrong things, or you do it too fast. It causes customer satisfaction problems.”
Alex believes that making a date the main driver is a bad decision. It’s better not to try to integrate a whole lot of new features, and to focus instead on more fundamental use cases and do them really well.
“I’m arguing with myself on this. An argument against this is, ‘software’s never done.’ Microsoft [might] not [have become] leaders [had they not] deployed stuff and said, ‘It’s good enough and we’ll fix the bugs.’”
Alex concludes that a good strategy is to find the right scope of features, release them, receive feedback, and make improvements, rather than try to include a whole load of new features that don’t work well.