At WealthTech Club, we want to find and show the best practices in creating successful WealthTech products. I travel around the US visiting the offices of WealthTech startups and meeting with their executives in order to get insights into their solutions. This has given me a unique chance to learn about real cases, to find out how the best WealthTech products are created, and to identify patterns that lead to the success of these companies and their products. I want to share this information with you in our new series of articles.
I have picked Trizic to begin with because in my mind the company stands out amongst other WealthTech startups. Its platform—for financial enterprises, advisors, and banks—is a bright example of the combination of everything you need to create an excellent FinTech software product. Indeed, the success of the company this year proves my words: Trizic Inc. has raised $10 million in Series A funding and was named the “Company of the Year” by CIOReview.
Due to our experience of software development for FinTech startups we have identified four major pillars of success for FinTech products, and I will examine Trizic’s platform from these four angles:
- Technologies and architecture
- Processes and workflows
- Team structuring
- Financial domain knowledge
Technologies and architecture
When FinTech startups begin developing their software products, they usually apply one of the following two strategies:
- Release a product as soon as possible in order to validate the business model and then improve the software and expand functionality. In this strategy, technical debt—in terms of monolithic architecture—arises.
- Apply the best overall software. This strategy takes longer and may result in releasing a product that is not needed because the market was not examined and the creators were not receiving feedback on their product.
Similar to most technology startups, Trizic’s initial software had a monolithic architecture. This architecture prevented the team from easily scaling the software development and this is why Steve Mays, CTO, decided to reengineer the application, taking monolith away—piece by piece—and building a microservices architecture.
When describing how Trizic has reengineered its platform, Steve Mays compares the process with repairing a freeway—you cannot just cut off the traffic, bring in the required machinery, and do all you need there. Instead, you have to consider how to divert or decrease the traffic while the repair work is being carried out.
The same can be said when running a business that has obligations to its clients and investors—you cannot just halt the work. However, Trizic succeeded in reengineering its platform and building scalable software. Steve Mays says that this has also helped Trizic to solve many performance and security issues.
At INSART, we always use the same approach to reengineer the software of late-stage startups. In our article about scaling WealthTech company growth, I wrote about the benefits of microservices architecture. The main benefit is the speeding up of development due to parallelizing the process because all features are created independently from each other. From our experience, I agree that it was a great step when Trizic decided to reengineer the system. Reengineering provides the means to facilitate further development and maintenance of the system, to improve the UX, and to fix long-standing problems.
Processes and workflows
Steve Mays is a strong believer that it is better to release an MVP, gather feedback, and then add features that clients need, rather than release a fully polished technology that nobody wants; therefore, he set up the CI/CD pipeline. But first, Trizic needed to establish automated testing in order to be able to test and deploy quickly. Today, once a chunk of code is ready it goes through deployment and test suites—which takes about 40 minutes—and it can then be deployed. However, Steve Mays believes that this process could also be broken up and parallelized to make deployment even faster; he compares the process with Henry Ford’s assembly lines.
Again, a microservices architecture allows the team to parallelize the process and thus to speed up deployment. In the case of the CI/CD approach, manual testing is an inappropriate choice and Trizic’s move to automated testing was absolutely correct.
Team structuring
Trizic’s engineering department includes cross-functional teams, each containing up to 10 software engineers, including back-end developers, front-end developers, system engineers, and QA specialists. I like this approach because well-structured, cross-functional teams can establish efficient coordination and thus reduce the development cycle.
As Trizic’s platform has evolved, they have faced the problem that senior developers with relevant expertise are not always available in the market. For this reason they built a framework where their junior developers are trained, directed, and guided by experienced members of the team. As a result, the junior developers can create quality code.
Here, I would like to compare Trizic with INSART. To train our developers and improve their skills, we show them the approved practices and explain the advantages of exploiting particular technologies; in addition, they observe common problems that arise, discuss ways to identify and resolve them, and are provided with examples of APIs and frameworks.
Financial domain knowledge
I am sure that in addition to technology knowledge, a deep understanding of the business domain has played a key role for Trizic. Its executives have considerable expertise in both the wealth and tech sides of their business. For example, Drew Sievers, CEO, has years of experience in strategic planning, advertising, marketing, banking, and financial services. Steve Lewczyk, CRO, has been in wealth management for approximately 30 years; he also built a data aggregation platform and launched wealth services for RIAs at Fidelity Investments.
With his background in supercomputing technology, internet technologies, telecoms, and electronic governance, Steve Mays felt that he needed to validate Trizic’s idea before joining the company. This is why he went to a number of industry experts, from Fidelity to small financial advisors, and asked them whether automation is required in the industry. Steve then became a part of Trizic when he learned that it was on the cutting edge of the new generation of technology.
Later, when creating new features, Steve learned about the space and appealed to advisors who would use the features to confirm that this is what they needed. This shows that to create a really good WealthTech product, even engineers need to understand the business domain.
At Trizic, however, they do not teach their developers much about wealth management, but they have created documentation for everything that is being done, including a summary for each feature and the entire product. They help their developers to understand what Trizic’s software is used for and how it helps advisors.
In Trizic’s case, they succeed in building a superb product due to the deep industry knowledge that the company’s executives have, even without sharing this knowledge and clarifying the details of each process to the technology team.
At INSART, in addition to expanding the engineering skills of our developers, we give special attention to their business knowledge. We have created a significant FinTech and WealthTech knowledge base that allows new developers to obtain industry insights, get to know approved practices, and receive clarification on the core aspects and critical issues. This results in high-quality software development without wasting time on miscommunication and rework.
Conclusion
Trizic is creating a really great WealthTech product thanks to applying the principles that most strongly correlate with the FinTech engineering approach that we use to help our clients accelerate software development.
