We ask – they answer. Our Delivery Directors speak.
Evgeni has a (PhD) from the Bulgarian Academy of Sciences – The Centre of Biomedical Engineering. He’s had 16 years of experience as a consultant, working on large-scale transformation, implementation and integration projects. Evgeni’s work has had worldwide ramifications, notably assisting in equipping IBM with a corporation-wide BI solution. Technically Evgeni is skilled in J2EE, MVC(JSF, Struts), JBoss Fuse and some ETL/BI/Database technologies and is more than competent to be both hands-on in a role as
well as design solutions.
What would your top 5 learning points be for startups in FinTech related to the delivery services pitfalls? What are some of the recent cases you have seen in your practice?
Working with startups is very interesting, especially with FinTech startups. The first observation I have is around the “disregard of the law” element. There are a lot of law regulations, especially related to payments and money involved, that FinTechs need to take into consideration and reflect in their solutions. You can have a UK-based FinTech and they build a solution which is not for the UK market. There are certain regulations in the UK, but the client is out of a different country, has different rules. You cannot change or improvise on these regulations but strictly adhere to them. If something goes to market without being compliant with the laws and regulations, you can face severe penalties and charges. So startups must pay really close attention to how they embed cross-border regulations into their product or service.
Another pitfall I see where start-ups fall is the inadequate market research of the clients for their business idea. The market is huge with many solutions in place. When a start-up gets the funding it is anticipated there is some uniqueness in the idea. To have that uniqueness you should have done detailed research on the market – there is nothing on the market yet or there is nothing in development yet. Market research impacts the post-delivery process. Once your product is done you need to take it to market and this is where the challenges arise.
Start-ups often rely on 3rd party delivery partners due to capacity issues or the inability to hire a full-blown technical team at the stage. Choosing the right partner is absolutely key to the success of the overall process. Start-ups have an understanding of the business domain, they are usually of small employee headcount, and may have some technical skills and expertise but not to the depth to be able to set the grounds for the right architecture or take sound decisions on this matter, especially if they require specific technical skills. Nowadays such decisions are being taken in big teams with strong expertise and skills. The world is no longer following the set-up of one person having an idea and bringing along a couple of developers to produce something. Today you need to rely on system architects, and DevOps, setting the right testing and quality assurance process and tools, securing the copywriters, and others. This makes the execution of the business idea very complex (that of course if you want to build it in the right way) as it requires significant knowledge in various areas. Start-ups don’t have a huge amount of permanent resources, as it is not efficient. This is why Startups would seek a 3rd party delivery partner to help out.
Another point, relevant to the delivery aspect is that startups usually start with a concrete idea, have a budget, and start working on the solution for their first client. The majority lack a wider MVP strategy as their MVP is made to the level for presenting and obtaining funding based on what a client has stated they need. Once the funding is secured then that same client says, “Let’s now make this product enterprise ready” but for his own enterprise-ready needs. If the startup lacks a strategic MVP vision then it will become very challenging to scale as the MVP will eventually come with multiple versions all specific to the given client or market. Remember in the beginning we touched on the laws and regulations. So if you are a UK-based FinTech building a solution for a German client then that solution will be specific for Germany. But if the German client stalls on the roll-out of the product and you are faced bound to engage with a new client, say an Italian customer, then your efforts may have been in vain or it will be extremely difficult to rewrite the German scenario to fit the Italian market.
This is what we are currently working on. We have a UK FinTech client that has built its first solution for the UK and now they have a client in Brazil for whom we are readjusting the solution to fit. They don’t have a canonical product that with minor changes you can adopt to the different markets.
When FinTechs start and let’s assume they have the right delivery partner, what sometimes is missing is the understanding of the needs of the client’s end customer. How will the client’s clients be using the solution? You could build a solution that may not be fast enough if the user experience is not the expected one. Unfortunately, FinTechs do not have the capacity to do that detailed user experience testing before taking the product to market simply.
Where do challenges arise in the ideation, development and implementation of a software solution and how does Estafet approach the resolution?
There are a lot of challenges related to ideation, development and implementation. Some are even related to the points we already touched on.
For example, when the MVP is defined it is expected to be delivered very quickly, usually within 3 months. Time pressure is very challenging when imposed by the client. In order to achieve this, the startup needs to have a strong competent senior team who has experienced such situations, have skills and expertise, know how to work under pressure, and deliver on time.
The world is changing very quickly and it doesn’t necessarily mean that your idea after 6 months would be of the same value and strength. Especially in FinTech if there are any law changes you have to reflect them from day 1 for sure.
What was the most challenging assignment you engaged in while in Estafet and how did you approach its solution?
I was involved in an enterprise integration platform team in Elsevier. This engagement was challenging in many aspects. The platform was supposed to manage multiple integrations of enterprise systems within Elsevier. We had between 30 and 40 completely different integrations that did not correlate with each other. At the same time, Estafet’s team was responsible for managing the platform where the integrations reside. We were not only responsible to deliver, manage, and maintain 24×7 but maintaining the platform and some pieces of the SaaS infrastructure they were running on. The platforms were on AWS, we also had OpenShift (Kubernetes), and WSO2 API Gateway and to manage those you need to be an expert in Kubernetes and WSO2. All of these platforms were running on very big clusters (for ex: the OpenShift cluster had 20 nodes), in three different environments and with multiple microservices in place. You need to be very well aware of what business these platforms are servicing and be able to maintain them with some edge cases.
We approached the project as we always do. The first thing we did was to form our methodology and manage expectations based on our company’s core values: be open and honest to our customers.
If we are not following some structure for working on such large-scale projects we can very easily lose ourselves in that big technology ecosystem.
When would you advise a start-up to outsource technical-related tasks and when should they keep such tasks in-house?
My experience says that startups should consider 3rd party delivery partners for almost every ticket or user story related to the technical strategy of the delivery of the product. By saying technical strategy I mean things around architectural decisions but not to outhouse everything. When it comes to the things related to the delivery of that strategy and the actual monitoring and controlling mechanisms that will be put in place, startups need to ensure that the two teams do not overlap. The team that does the delivery must be different from the team that monitors and controls the delivery. In some cases, I can recommend they keep the monitoring and control in-house. Our engineers are specialised and startups can hand over such tasks to us. I think Estafet is now a completely defined development service and delivery partner. We know how to approach the MVP, we understand architecture, we think generically, to have an abstract layer which could be canonical engineering, avoiding silos thinking, and we know how to deliver, monitor and control.
In your view, how is Estafet different from other nearshore delivery partners?
We know how to deliver – we have a strong team, delivery methodology proven over 20 years, know how to think strategically, know how to deliver under time pressure. We have a solid domain knowledge to develop and implement the products and platforms correctly in FinTech, Data Tech and BioTech segments.