The Dilemma
In the fast-evolving landscape of trading, the decision to build or buy software solutions is a decision that requires strategic foresight. The age-old debate covers a variety of factors such as cost implications, efficiency considerations, ongoing support, time investment, potential distractions, and the advantages of in-house development.
In order to keep up with the intricacies of financial markets and remain competitive, trading firms often find themselves at a crossroads when it comes to deploying new technology. The allocation of limited development resources to more revenue-generating projects like building out your trading services leaves decision-makers with a choice: pull those resources off these existing projects, or simply place this new technology project in the ever-growing development queue. Additionally, asking whether your firm truly possesses the business and development resources internally to deliver any fit-for-purpose software is a crucial step in this process. In many conversations FixSpec has had with the market, the answer is often no.
Opting for cheaper alternatives, such as generic software development firms, may seem tempting, but these companies often lack the domain-specific knowledge to achieve the best outcome. Similarly, the allure of open-source solutions for junior developers to tinker around with might initially seem cost-effective. However, hitting functionality ceilings relatively quickly and these solutions might struggle to align with the long-term strategy.
Domain-knowledge also remains a critical factor. While external vendors may bring expertise in software development, they might lack a nuanced understanding of your specific trading workflows and strategies. In contrast, in-house teams possess deep domain knowledge but might face challenges in keeping up with the latest technological advancements. External vendors may expedite the requirement definition phase, but long-term commitments and potential limitations in flexibility must be weighed against the advantages.
Firms face a decision: burn resources to build and support software or work with external entities that might not fully understand their workflows, potentially leading to restrictive solutions.
In-House Development
Creating software in-house offers some advantages, making it an attractive option for many trading firms. One of the key benefits is ownership of IP. In an industry where proprietary strategies and technologies can be a source of competitive advantage, having control over the IP can be a strategic asset.
We do sometimes come across the approach of “we only develop in-house” which likely stems from an unrealistic expectation that comes from being a fintech firm or a sense of ownership. Firms also can create tailor-made solutions that align perfectly with specific business needs and retain control over the evolution of a project. This level of customisation can be hard to achieve with off-the-shelf solutions from external vendors, which are designed to cater to a broader market. Internal teams also have full control over maintenance schedules, updates, and troubleshooting, enabling them to address issues promptly and efficiently and minimise the risk of an interruption in trading. The ability to integrate in-house solutions seamlessly with legacy infrastructure can be another advantage; in-house development provides the flexibility to ensure new solutions work effectively with any existing systems.
The increasing emphasis on cybersecurity and data privacy also influences the decision-making process. Trading firms, dealing with sensitive financial data, must ensure that their software solutions adhere to the highest security standards. This consideration may tilt the scale towards in-house development, where the firm has more control over security measures.
Using an in-house developer will on the face of it be seemingly cost-neutral but has its own set of associated costs. These costs may not be explicitly invoiced, but they include the time and effort of internal developers that could be directed towards other more revenue-generating tasks. Additionally, building custom software often incurs higher initial costs due to development expenses, resource allocation, and infrastructure requirements. When contemplating the true cost of in-house development, it’s crucial to factor in fully loaded salaries, ongoing support, and the potential risks associated with developer turnover.
What happens if the person who developed the software in-house exits the firm? The firm may find itself in a precarious situation, especially if the knowledge isn’t adequately documented or transferred. We often hear about a patchwork of code in trading firms creating significant technical debt. The associated risk shows the importance of assessing the long-term sustainability and maintainability of internally developed solutions. The extensive resources and focus required for development could detract from core competencies, impacting the overall efficiency and risk an interruption in service for your customers. It’s essential to question whether reinventing the wheel through in-house development is truly worth the investment when third-party solutions exist in the market.
The Vendor Conundrum
Many firms grapple with prioritising software projects when considering an internal build, often relegating them to the “low priority” category. However, these projects should be far from a low priority for the business. Engaging with an external vendor can kick off the project sooner and also significantly expedite the development timeline.
Engaging an external vendor can significantly reduce the effort in any requirement definition phase and can save time spent on finding resources and managing sprints. This time factor cannot be overstated. A firm’s development team will take significantly longer to reach production than a dedicated third-party software vendor who will have a production-ready product ready to install. This delay could mean the difference between staying ahead of the competition and lagging behind.
Yes, third-party software might appear more expensive on paper, but compared to the fully loaded cost of developers and the time delays, it can quickly become comparable if not cheaper. The time to go live is likely to be significantly faster and any ongoing maintenance, upgrades, and support will not need to be handled by your internal teams.
The benefits of an external vendor do however have to be weighed against the long-term commitment and potential limitations in flexibility. Reliance on external vendors can raise concerns about being tied to a specific vendor indefinitely. Firms will need to return to the vendor each time a change is required. This might potentially lead to a loss of control over the software’s evolution or delays in changes being implemented.
Future Outlook
Looking ahead, the future of the build vs buy decision in trading is likely to be affected by technological advancements, market dynamics, and evolving business strategies. For example, the rise of low-code and no-code platforms has introduced a middle ground, allowing firms to develop custom solutions with reduced development times and costs. Advancements in artificial intelligence and machine learning are also poised to play a significant role in the development process. Firms will then face a new decision whether to build up in-house specialists or rely on external expertise.
The role of the development team has also evolved. Traditionally focused on building solutions from scratch, development teams are increasingly becoming integrators, leveraging pre-built components and third-party solutions to accelerate development cycles. The trend towards hybrid solutions, combining in-house development with third-party components will likely become more common. Additionally, as the regulatory landscape evolves, compliance requirements become a crucial factor in the build vs buy decision. Third-party solutions must align with regulatory standards, and in-house development teams need to stay abreast of changing compliance requirements. Striking the right balance between compliance and innovation will be a key challenge for trading firms in the coming years.
Conclusion
In conclusion, the “Build vs Buy” debate in software development for trading firms remains a challenge that demands a nuanced and strategic approach. Firms should be open-minded to both build and buy, rather than being married to one approach; neither option is universally superior, and context is key. Firms should weigh up the short-term benefits against long-term sustainability, and align technological solutions with the overarching business strategy and resource availability. The “Build vs Buy” decision is not a one-time event but an ongoing strategic consideration that evolves with the ever-changing dynamics of technology and business.