Build or Buy a FinTech App?

© Rawpixel.com/Shutterstock.com

Whichever choice you make, success is driven by thorough planning and clear communication.

Is this functionality core to your business?

Put your development dollars into the creation of code that provides your business market differentiators. If it isn’t core to your financial objectives, you’re stealing money from other areas of the company that will generate business. Even if you have the greatest development team, if what they’re developing is peripheral to their area of expertise, the net effect is that the software will rapidly degrade and become obsolete over time. Identifying what is core to your business is key to your success.

Is the application unique?

On the other hand, if the application you want is unique and original, you won’t find it on a third-party vendor’s product list. To get the features and capabilities you want, you may have to either build it yourself or start with something generic and modify it to fit your use case. The latter is often your best bet; it’s a much less daunting proposition to modify an existing application than to start from scratch. Finding applications that are extensible, that are used for many operations, or that integrate easily with other applications and can share databases is a real positive for a rapidly expanding company. Such an application can grow with the needs of the organization while requiring less specialized support.

If you choose to go the third-party modification route, you need to make sure that it can be done contractually and that the core third-party application will continue to be supported and updated over time. A thorough review of the application programming interfaces (APIs) available for the product is critical.

Which approach is more cost-effective?

On the surface, the question seems like a no-brainer. Buying is cheaper than building, by tenfold. In other words, it costs ten times more to build a system than it does to buy an equivalent system. The maintenance costs are higher for house-built systems, too — 40 to 60 percent more over seven years than the same large, complex, modified vendor model. This is mainly due to economies of scale because a vendor can build a system once and then sell it to many customers, whereas if you build a system yourself, you are its only customer.

On the other hand, buying carries its own cost burden, including costs specific to the deployment, both before and after, and annual fees, both maintenance and support, over the life of the contract. With that said, one of the most compelling arguments for buying is that you don’t have to deal with legacy systems, and the technology that’s purchased is constantly being rejuvenated over time.

Buying software means paying upfront for the licensing and then (usually) paying again each year for support. License fees can be not only for the software but also any peripherals that are needed to support the software.

Look at the projected costs of a live contract over seven years to determine the all-in costs of a purchase versus the all-in costs of an in-house development. You also need to reflect on the cost of deploying the software. Vendors will supply estimates. Be sure to tack on 10 percent to their estimates for hidden and internal costs.

Should this application be built?

• The nature of the application: If it’s unique and/or critical to your core business, build it. If neither are true, buy it.
• The need to control the nature of the application: In-house building means you have more control and privacy. Privacy can be an issue if it’s important that the code not be shared with other organizations.
• The cost to build, maintain, and support it: Buying is nearly always cheaper, as we explain in the previous section.
• The risks involved in the development and maintenance: If you can’t afford for the system to go down, or if you don’t have the in-house staff to support it, you should buy. (More on risks is in the next section.)

The availability of robust Software as a Service (SaaS) offerings has lately shifted the balance in favor of buying or subscribing for many organizations. SaaS has substantially altered the need for organizations to own, build, or maintain generic software. SaaS is generally rented on a subscription basis. It’s offered in the cloud, which makes it ubiquitous, and it scales based on user and compute requirements. The vendor provides all support, maintenance, and automated upgrades. This model is particularly appealing to small and start-up organizations.

Everything is a trade-off. Within the build versus buy discussion, the amount of control you have is inversely proportional to the cost. Buying the product is less expensive than building it, but you have less control over the direction, distribution, focus, and support of a third-party licensed product than you do over a unique in-house project.

What are the risks of building versus buying?

• If you build, the time to delivery is your highest risk. Proper project management can help mitigate the risk of failed delivery dates. Schedule slippage is less of an issue when buying because the software is already created and needs only to be integrated with your systems.
• When buying, the lack of access to source code can be a risk. You must rely on the vendor to address concerns, fix bugs in a timely manner, and develop new functionality in response to your requests. If the vendor doesn’t meet your support needs, you may find yourself stuck with them anyway because of your contract, or because it would be too expensive to change to a different vendor.

Due to personal information retention and privacy laws, and country-specific regulatory controls, data management and visibility are also mounting concerns. If you allow a third-party vendor to store and manage your data, it’s important to choose a vendor that will keep you well informed about what’s happening with your data and what security risks their network may be facing. If you manage your data in-house, you must be responsible for adhering to all regulations yourself and bearing the administrative costs of that.

When does open source make sense?

Open source also mitigates the issue of some elements of control. Your team can develop custom work for critical functionality not currently in the open source package. It can also release updates in an automated fashion, taking advantage of the changes noncompany developers have made. By always contributing new code back to the project, the user company is assured of backward compatibility and shorter update cycles.

Unlike vendor code, open source code isn’t a black box. It utilizes the more flexible newer development processes like microservices and is cloud-enabled.

The open source community is robust and should be utilized when doing due diligence on any project you’re entertaining.

• Bitbucket
• Tigris
• SourceForge
• OSDN
• Freecode
• FossHub
• GitHub
• LaunchPad
• Open Source Software Directory

• Does it have a large user base?
• Does it have a good reputation?
• Is it interoperable?
• Does it require specialized skill to use or maintain? If so, this could be costly.
• Does it have sufficient, well-written documentation?
• Does it have a good support network? The support network includes a community as well as paid support options.
• How often has the code been updated since its inception? What is its most recent update?
• Is the project site well trafficked and well maintained?
• Is the open source license associated with the product clearly defined?
• Is there any larger group or company supporting the development of the project?

Frequency of updates to the code, longevity of the project, good documentation, and a large user and support group are clear indicators of a successful open source project.

When does building make sense?

• Does the software have specialized functionality that only your company needs?
• Does the software need to be customizable? On the fly?
• Are data control, security, and privacy a must?
• Is the output or the workflow specific to your company’s use case?
• Have you searched and not found software that solves your critical problem?
• Does your company have the IT and developer resources to create and maintain the software?

The benefits of building can be summed up in one word: control. With building, you own the code and the functionality being built.

How can we accelerate a build?

• Customer relationship management (CRM) systems
• Content management systems (CMS)
• Business process automation systems
• E-commerce software solution
• Business portals

For such collaboration to be successful, the vendor must assemble a very exacting set of requirements, objectives, and deliverables. An expert project manager is key to staying on schedule, along with having a concrete statement of work.

Another way to speed development is to embrace DevOps, which is a new discipline that automates standardized operations and processes used by development and quality assurance teams. It’s an outgrowth of the small cross-functional teams used in open source, microservices, and Agile-like development. DevOps is for automating processes in a controlled way, developing continuous integration and deployment environments. Automation and continuous integration make it easier for teams from different organizations and different locations to work together in real time.

Application programming interfaces (APIs) in third-party software make it easier and faster to deploy third-party code. They enable internal developers to collaborate with third-party vendors and open source projects easily. In-house developers can utilize APIs to build layers of functionality on top of a third-party black box or to make their software available to a third party without revealing any of the corporation’s secrets.

When does buying make sense?

One of the most critical questions to ask is, “How soon do you need this functionality?” If your answer is “now” or “very soon,” then buying is your solution.

• The functionality is ubiquitous and used across companies.
• It isn’t core functionality required to drive the company’s success.
• It’s outside the company’s area of competence.
• It isn’t cost-effective to build or maintain.
• Development of it deflects labor that could be working on more core functionality and thereby takes money away from the company.
• Applications already exist in the marketplace that can be deployed out of the box, that are mature and bug-free, and that have a support and user network.

Just like building, buying has its own set of liabilities. With buying, you own nothing and are completely dependent on the supplier. You have no control over data integrity. You can’t dictate the levels of security, and you can’t drive the areas of new functionality. And if the vendor goes out of business, you may lose your software support and be unable to get updates.

If the application you’re selecting is important to the day-to-day operation or to the company’s bottom line, you may want to build an escrow component into the terms of the contract.

• The request for proposal (RFP) process could be flawed and the product may not match the company’s needs.
• If the application is being integrated into some other system, there may be compatibility issues.
• It may take more time to deploy than anticipated.

How do we select a vendor and a product?

• Has economies of scale.
• Provides support and training.
• Has a focused skill set that drives development and functionality of the application.
• Has a proven track record for supplying needed functionality.
• Has designed the software to be flexible and interoperable.
• Offers regular reviews and upgrades, making the software future-proof.

Many vendors offer multiple software products to choose from. Before you finalize your buying decision, you should be thoroughly familiar with the software, its capabilities, and any potential drawbacks, including any areas where the vendor doesn’t provide strong support.

• How often is the software updated?
• What does the update process look like?
• Is there free software training? If not, what type of training and cost is available?
• What is the level of support during deployment? After deployment?
• What type of reports are available out of the box?
• What other software does this system interface with?
• What are the hardware requirements?
• What is the cloud capability?
• What is the mobile capability?
• How is data integration carried out?
• What is your road map for the product’s future functionality? How far out does the road map go?
• What is your security model? Have you ever had a breach?
• What certifications does your system and team hold? Do you have a Service Organization Controls (SOC) report? What is your disaster recovery plan? Has it been tested?
• What is your data management plan, and what is your data disposal process?