Build vs. Buy

Internet businesses need automation for their complex finance and accounting processes now more than ever. But when bombarded with SaaS solutions in the marketplace, the build vs. buy discussion inevitably arises.

Building financial systems in-house may be worth the investment for large corporations with complex back office processes and an abundance of resources. But for high growth companies, the opportunity cost of investing resources in non-revenue drivers can hinder business growth at a time when speed is of the utmost importance.

Let’s take a closer look at the considerations below and evaluate whether build or buy is the right decision for your team.

What is your timeline for deployment?

One of the main downsides of investing in an in-house system is the time required to build, test, and implement the system before it can be up and running. Finance must wait for engineering to build the system and be patient if higher priority projects arise that demand engineers to shift focus. The technical side of building a finance system can also prove to be more complicated than imagined – building the necessary features and integrations increase complexity and can significantly prolong the development cycle. Not that there aren’t enough hurdles to jump over already, but let’s not forget the inevitable corporate politics that delay the timely completion of any internal project.

On the other hand, SaaS finance software is pre-tested and user-validated through years of iteration. SaaS software for finance teams typically come with APIs and built-in integrations (payment processors, billing systems, sub-ledgers, ERPs) that require minimal engineering resources to deploy. SaaS vendors also provide specialists that facilitate the on-boarding process for both finance and engineering teams.  The majority of time is spent during the implementation period, which may differ between SaaS vendors.

If time is your enemy, it’s best to go with a pre-tested and user-validated SaaS product that can be up and running within a few months.

What is your budget?

Building an in-house system requires significant upfront investment, including infrastructure cost and engineering resources (average fully loaded engineering FTE is ~$150,000/year). However, companies typically underestimate the ongoing maintenance costs required after development is completed. Dedicated engineering resources must be allocated to system maintenance for bug fixes, new feature development, and improvements to ensure the system remains relevant to the company’s changing business requirements. Needless to say, it is difficult to estimate how much an in-house system will cost given the various factors that affect ongoing costs. According to a McKinsey study, 66% of software IT projects ran over budget.

With a straightforward annual subscription fee, SaaS solutions are more transparent in terms of cost so going over budget is rarely a concern. Training, implementation, and ongoing support are typically included in the upfront cost or as a separate professional services fee. In addition, SaaS software providers will regularly release new features to remain competitive in the marketplace.

For predictable and transparent costs, opt for SaaS solutions with a simple annual subscription fee.

Does your team have domain expertise?

Successfully building an in-house system requires a combination of both IT and finance experts to manage the project. But when building software that does not fall under the company’s core competency, external consultants are necessary to ensure project success. However, external specialists are costly (upwards of $150,000 in the San Francisco Bay Area) and hard to find. If the company does not hire specialists, finance and engineering resources will need to be allocated to the project. There are significant opportunity costs of staffing finance and engineering on back office finance system development when they could be contributing to revenue-driving activities.

SaaS vendors in this space are specialists in building and maintaining finance software. After working with clients of all sizes to pioneer best practices for their products, SaaS vendors can also serve as specialist consultants in their areas of expertise. They’ve gone through implementation with many other customers and will proactively address potential issues that may arise from particular business complexities. Finance teams can rest assured knowing that they have knowledgable partners throughout the whole process.

Rely on a SaaS vendor for domain expertise unless building finance software is part of your company’s core competency.

How much customization and control is necessary for your finance system?

The best reason to build your own finance system is that it is custom built for your organization and can be tailored to any edge case scenario. During the development phase, finance can work with product teams to identify upcoming product changes to incorporate into the new system.

Your finance team also has full control and access to the underlying data and code used to power the system, therefore eliminating any vendor dependencies. As your business grows, you can engineer your finance system to serve evolving business needs without having to depend on a SaaS vendor for product customization. However, it’s important for finance teams to keep in mind that customization and flexibility are limited by the amount of engineering resources allocated to the project. Setting expectations early and ensuring communication between finance and engineering teams can be key to managing project success.

A SaaS product typically prioritizes features that support common customer use cases and offers a limited amount of customization. But for earlier stage SaaS vendors where there is more product roadmap flexibility, key customers can influence or request new features. Furthermore, SaaS products built on the cloud are designed for scale. Despite limitations with customization, SaaS products will grow with your company.

Building your own in-house system will give your team complete control and customization.

In the end…

It comes down to evaluating the opportunity costs:

  • What will it mean for your business if the finance system is deployed in 2 years vs. in 3 months?
  • Do you have the resources and domain expertise needed to build an in-house system?
  • How will revenue be impacted if engineers work on back office systems instead of customer-related work that can drive revenue?

Generally speaking, high growth Internet companies should:

Buy SaaS solutions to solve a non-core business problem

Build in-house systems related to their core competencies, key revenue drivers, and unusual use cases

How is your finance organization tackling the build vs. buy issue today?