Skip to main content Skip to main menu

Your choice regarding cookies on this site

Our website uses cookies to offer you a better browsing experience, analyse site traffic, personalise content, and serve targeted advertisements. Please visit our Cookie Policy page for more information about cookies and how we use them.

Manage Cookies

Separating Hype from Fact in the “Build v. Buy” Debate

Separating opinion from fact in order to come up with the best recommendation for your business can be a challenge, especially in a large organization where multiple groups have a stake in the outcome. 

When it comes time to roll out a new technology solution for your business, it’s almost inevitable that you will get embroiled in the “build versus buy” debate at some point. That’s not a bad thing - as long as the discussion happens early in the project, and is based on fact rather than opinion. But separating opinion from fact in order to come up with the best recommendation for your business can be a challenge, especially in a large organization where multiple groups have a stake in the outcome. 


While researching the topic of Build v. Buy I came across this illustration and felt compelled to share it:


It caught my attention not just because it strongly supports the “Buy” argument, but also because it highlights some critical aspects of product development that are frequently overlooked when scoping a project, such as:

  • Late-stage specification changes that significantly impact schedule and costs
  • The reality of ongoing development, maintenance and updates
  • Lost opportunity costs when highly-skilled resources are tied up in bespoke product development and deployment

pTools is a software company so we obviously have a bias towards “Buy” - it’s how we stay in business after all! But we’re not in the business of convincing potential customers to go down a specific path. Rather we work hard to be a trusted partner, which means giving you the information you need and letting you decide what’s best for your organization. Our bias is based on hard data - from our experience working with other financial services clients; in the findings of other software and services companies; and in published third-party research. 

On the other side, selection bias can creep in from many sources. In a recent article in CIO Magazine, Chris Doig, CEO of Wayferry (and author of the book Rethinking Enterprise Software Selection) points out that most organizations rank low on the Software Selection Maturity Scale, causing teams to over-index on “gut feel” when making build v. buy decisions. In practice this means requirements are not fully scoped up front, and analysis of commercial off-the-shelf (COTS) solutions alongside in-house capabilities and solutions lacks rigor and objectivity. It’s a compelling perspective and well worth investigating further.

Whatever the source, the key factors that consistently show up as significant influencers in the Build v. Buy decision model are:

Speed of Deployment

It’s almost impossible for an in-house team to scope, develop, test, refine, harden and deploy an enterprise solution in less time than it would take to roll out a commercial off-the-shelf (COTS) solution. Even if the COTS solution requires significant customization you’re still starting from a stable, thoroughly-vetted code base, which means resources can focus on developing the incremental features and capabilities you need to meet your specific business requirements. And it’s not just development that’s faster. Initial project scoping can be more focused and completed faster. QA takes less time. Development of documentation and training materials takes less time. Translation and localization is faster. And in many situations the process of rollout, activation and user onboarding is greatly accelerated because COTS manufacturers like pTools design rapid adoption capabilities right into the product, rather than tacking them on as a post-development pro-serv function. 


This is always one of the top arguments for developing products in-house, yet it rarely holds up under scrutiny, for three major reasons:

  • Many project costs are heavily discounted or completely written off - in house development staff, IT resources and infrastructure, and existing enterprise apps being some examples. Additionally project cost models rarely include project management, deployment and training resources and infrastructure costs. For large global projects this can translate into hundreds of thousands of dollars that never show up on the project balance sheet.
  • Project cost models are frequently optimistic, and bounded by the initial scope and timeline. In other words, projects tend to get funded at the best-case scenario level, and usually for just the initial development and rollout phase. As illustrated at the top of this blog, that theoretical viewpoint rarely translates into reality. And when the schedule slips, or the project scope increases, or other unforeseen issues arise, project and finance teams have to get creative in how they account for the cost overruns. In many situations these costs never get directly mapped back to the project.
  • Even more significant that the project costs are the hidden sustaining costs. Additional development costs - adding modules, new features, API integrations and so on - may get billed back to the business unit or the project, but the cost of sustaining the solution is frequently distributed across IT, Training, Documentation and Development teams and never fully accounted for at the project or solution level. 

How much of the above rings true for you? How tight is your cost accounting when you develop products in-house? Have you ever signed off on a project, knowing that the allocated budget is less than the anticipated costs?

Ongoing Maintenance, Development and Support

As noted earlier it’s easy to under-estimate the total cost of in-house development if you exclude maintenance, support and development costs from the equation. And those costs can be massive - in some instances even more than initial development costs. In "Frequently Forgotten Fundamental Facts about Software Engineering" by Robert L. Glass, he states that maintenance typically consumes 40 to 80% (60% average) of software costs. Feature enhancements account for roughly 60% of this figure, with bug fixes accounting for another 17%. So a $200K development project can easily end up costing $120K+ in maintenance costs each year. Compare that to a COTS solution where maintenance fees are closer to 15%. Why such a significant delta? Because turnkey software vendors can amortize maintenance costs across all customers, whereas in-house developed solutions have an audience of one.

But cost is not the only element to consider. Software applications are increasingly modularized - front end, back end, mobile, database, APIs and sub-systems like blockchain, authentication, comms, NLP & AI - and developed by specialized teams. It’s simply not feasible to retain all this expertise in house for ongoing maintenance, leaving you with some sub-par choices:

  • Have generalists on staff who span multiple domains but with limited depth of knowledge
  • Use specialized contractors for software updates, with the understanding that they don’t know your code base, and you have limited control over their work product

Unless you have impeccable processes and systems in place for software management - code check-ins, well documented QA processes, exhaustive testing, code rollback methodologies, etc - over time your code base will become increasingly complex and unstable. In the same Fundamental Facts article, Glass states that for every 10-percent increase in problem complexity, there is a 100-percent increase in the software solution’s complexity. When you layer in embedded third-party applications and modules that are executed via APIs it becomes clear that the burden on in-house engineering, QA and documentation teams is simply not sustainable. 

And all of this needs to be considered within the broader technology landscape, where the average lifecycle of an enterprise app is 5 years before it becomes outdated. 

Opportunity Cost

Tightly coupled with the previous factor, lost opportunity cost is rarely included in the overall expense model or decision making criteria. The definition of Opportunity Cost is the benefit not received as a result of not selecting the next best option. In this context it’s specific to your technical resources and the impact of their effort on business results. When you embark down the path of creating high-value or mission-critical software using in-house resources, you must a) choose your best team members and b) commit their time for up to 18 months in order to deliver a high-quality product. Now as far as the company is concerned, those resources no longer exist. They’re not available to work on other projects, which limits the company’s ability to pivot and jump on a trend, or quickly resolve a major customer satisfaction issue. This is the (lost) opportunity cost of in-house development. 

Even worse - but frequently seen - the resources are split across multiple projects, slowing down the delivery of everything.

Ownership and Control

The desire to own and control all aspects of the code used in a long-term, mission-critical application is understandable, and makes sense in a very narrow band of cases (ref the Forbes article below for more on this). If you develop a solution in-house you can build it to your exacting specifications, change it as you see fit, and never have to worry about dealing with a third party vendor. But as stated in the Peter Parker Principle, “with great power comes great responsibility.” In the case of software that responsibility is measured in performance across a breadth of criteria - speed, security, usability, scalability, throughput, resilience, uptime. As the developer of the product, your team bears full responsibility for ensuring the customer is satisfied. And it’s never pleasant when you let down your co-workers or impact the overall business.

Changing sides for a moment, what’s your typical response when a vendor fails to deliver on a project, or to hit a key performance index (KPI)? You hold them accountable to the contract, right? Well written contracts include a host of clauses designed to protect you and your company - from penalties for late delivery, to protection from third-party litigation, to code escrow in the event they go out of business.

In short, you get all the control you might need by using the contract to full effect - and your liability is significantly lessened in the event anything negative happens.

Build has its place

In his March 2020 article, Bo Hagler of the Forbes Technology Council laid out in very succinct terms why Buy is generally a better option than Build, while also acknowledging there are situations where companies may still choose to build their own solutions. Here are the key things you should objectively consider before deciding on the best approach for your next project (and note: “keeping developers busy” was specifically excluded as a qualifying criteria!). 

You Should Buy if...

You Should Consider Building if...

  • Building software is not a core part of your business.
  • There are already solutions on the market that address your business challenges.
  • Internal resources are limited, and need to focus on core competencies rather than software development.
  • Fast deployment is a higher priority than a fully customized product.
  • You wish to leverage your own unique intellectual property and want to limit external knowledge of the technology; especially relevant if you plan to monetize the product or IP.
  • You need to fix a single issue e.g. developing an API to enable data flow between disparate systems
  • Your requirements are so exacting that existing systems cannot be tuned or customized to meet the need.
  • Your specialized requirements can only currently be addressed by two or more off-the-shelf products and would require extensive customization and integration to get them to work together.


Whether you ultimately choose to build or buy, you need to apply exhaustive rigor in the requirements definition phase to ensure you get the best possible product, today and in the years ahead. It may be tempting to just poll the line of business (LOB) and IT teams to come up with high level requirements, and then iterate with them to add depth. But you run the risk of missing out on major trends in technology or in business. An example of this in recent times is the integration between LEI and ISIN databases. Unified access to both data sets is clearly of value, but this would likely never have surfaced as a requirement in a solution spec. Similarly, emerging technologies like blockchain, digital signatures, natural language processing (NLP) or even API development trends might not make it onto the list unless someone specifically does the analysis and has an eye “over the horizon.”

And that last item - the ability to see over the horizon - is perhaps the most significant reason for working with a software developer like pTools rather than going it alone and developing software in isolation. We have developers who focus on the latest trends and technologies, as well as business analysts and leadership plugged into the changing world of finance and regulations. Together with your in-house teams and domain experts we can deliver tailored solutions to meet your exact needs. And yes, we’re still convinced we can deliver them faster, at lower total cost, and with a higher level of quality and sustainability. 

Request a consultation with pTools today.