Build Vs Buy the Software: A Detailed Decision-making Framework

Two roads diverged in the “software industry”…and these two industrial companies chose two different paths to realize their software goals.

RXR Realty, one of the largest office property owners in New York City, built the platform RxWell, which includes RXO Home App, enabled RXR’s tenants to see cleaning status, air quality, and occupancy level of the building to make the “work from office” experience safer for them. The move led RXR Realty to witness a 2x increase in retention rate for tenants vs. industry average during the pilot.

Titan Company Limited that revolutionized the watch industry 30 years ago, on the other hand, rolled out a third party CRM software solution in 350 Tanishq Jewelry Stores, which enabled them to “build a 360-degree customer view to engage better with customers,” according to Sanjay Bhattacharjee, Head of Customer Relationship Management at Titan. The software implementation resulted in conversion increase by 3%-4%.

But which one was a better approach and who achieved a better outcome?

Well, it is like comparing apples to oranges. What’s worth looking into is the factors that made one choose to build and the other to buy the software, which vary from industrial backgrounds to the goal of the software and existing IT infrastructure to past experience in technology.

At the crossroads to build vs. buy software, you would find footprints of many such companies to lead your way. But at the same time, you have to create your own route by assessing critical factors of your software project.

On the way, you can use this framework as a sign board that relays messages of what would work and what may not work for you. Tread lightly though!

Assessment Framework: Build in-house or buy an off-the-shelf software product

Once you begin your journey to giving a solid shape to an idea or resolving the business problems through the software, your mind may get clouded with buy or build the software dilemma.

This build vs buy decision framework is designed to provide you a see-through vision of the software project factors, and what it would take to make choose the best approach to achieve your software software goals.

The framework consists of 4 key software project factors and their strategic decision drivers, as stated below.

Software project factors Strategic decision drivers

Project fit-gap analysis

• Competitive differentiator or
  operationally critical
• Feature fitment
• Capital investment

Compatibility and flexibility of technology platform

• Time to market
• Technology stack
• Customization flexibility:
  Code and UI
• Integrations and scaling
• Data migration and import options
• Security

Cost considerations

• Upfront investment
• Hidden cost
• Ongoing cost
• Cost of innovation
• Total cost of ownership

Upgrade and support

• Consultation and support
• Hiring and training staff
• Upgrade

We will go a little further to understand how each component of the software project factors in build vs. buy software framework impact the project and its outcome.

1. Project Fit-Gap Analysis

Competitive differentiator or operationally critical

What problem are you trying to solve with the software? Is the digital solution underpins your competitive edge or simply solves the internal administrative issue?

For example, Deere, a leader in the farm machinery and equipment industry, launched JDLink that enables equipment tracking and sharing of alerts and information, including the location of the equipment, their operating efficiency, and maintenance data. With this successful launch, Deere rewarded shareholders with a total shareholder return of 222% in 5 years.

Well put by Scott Andrew, COO of the Commercial Division at BOK Financial that “it makes a lot of sense to own something that is your ‘secret sauce” in an article published by Deloitte.

But will the same decision make sense now? Especially when there might be a lot of solutions that could be available at 20-30% of the lifetime cost of ownership?

And so, this does not really mean you are only left with building the software from scratch. A viable workaround is to own the front end design and experience, while buying the critical platforms, according to Mr. Andrew. It would help you to use the world-class, proven options available in the market while reducing your overall costs and time to market.

Feature Fitment

Does the off-the-shelf software cover your unique needs or 80% of all your requirements?

Or

Does it provide the flexibility for code configurations?

You could use the MoSCoW method to prioritize your feature requirements. It refers to:

• Must Have: The absolute must
• Should Have: Essential but not critical
• Could Have: Significant but not urgent
• Won’t Have: Irrelevant for now

If the software you are planning to buy satisfies all the criteria of the first two elements, it might look like a good-to-go option. But there is a catch. If you choose integrations or configurations to meet the deficiencies of any MoSCoW element, it would increase the total cost of ownership of the software product.

Capital Investment

A common mistake that most executives commit is treating a software project as temporary. IT is a dynamic industry and that a 3-year old product may get outdated.

No matter what you choose between buy vs build software, it is never going to be “this is it…We have got our software, and now we can look into other tasks.”

Just like your operations, it would be ongoing. So when deciding on capital investment you may require to think from a long-term perspective.

2. Technology Platform: Compatibility and Flexibility

Time to Market

“In the past, big companies outcompeted smaller companies. But that’s history. Today, the fast companies outcompete the slow companies,”—Ulrik Nehammer, CEO, Coca Cola, Germany.

How quick you want to bring that idea into the real world also impacts your buy vs. build decision.

For example, a simple mobile app with few functions takes around 4-6 months. But such apps have a short lifespan. Apart from general maintenance and app store upgrades, you may need to rewrite or update the code within 2-3 years.

But a software like a fully-functional maintenance platform or service CRM may take around 2-3 years from ideation to final release. Generally, a CRM software consists of both web-based and mobile app solutions. If you decide to build a custom application with premium capabilities such as analytics and AI-driven automation, 2-3 years are bare minimum to achieve product maturity.

Besides, schedule overruns are still rampant. A study by Harvard Business Review found that around 70% of the IT projects have schedule overruns. While it is reassuring that the IT project success rate has improved since 2016, it is still hard to promise the same for schedule overruns.

Technology Stacks

Technology stacks covers everything from programming languages to frameworks, and purchasing licenses for supporting software from server-side to developers’ community of the platform.

It is one of the most critical aspects of software that would determine most software strategies and cost in the present and future, whether you buy or build the software. A rule of thumb to follow is the software development technology stack is mature and compatible with your existing infrastructure and has a strong developer’s community.

Also, anything you would buy or hire would have a direct and huge impact on the cost.

Integrations and Scaling

According to Ron Shevlin, research director at Cornerstone Advisors, the buy vs. build dichotomy should be viewed as, “build, buy, integrate, enhance, and partner,” reflecting what Microsoft CEO, Satya Nadela has said—

“All companies are software companies. It’s no longer just about procuring one solution and deploying one. It’s really you yourself thinking of your own future as a digital company.”

An off-the-shelf-software that is purpose-built to integrate with other applications and support APIs could be your stepping stone to a digital future.

As proven integration abilities means to keep the doors open for acquiring new digital capabilities, scaling when business grows or add on capabilities when disruption happens.

Customization Flexibility: Code and UI

It is possible that even if an off-the-shelf software meets 80% of your requirements, you may have to create custom code to enhance a feature.

While it is recommended to use standard objects and declarative features in the packaged software, many vendors do allow you to create custom codes on top of the platform for greater flexibility. But an important aspect you need to check here is how the customization would impact the upgrades and support requirements.

Offering UI customization is quite common by off-the-shelf software providers, but that is more important when you are managing a B2C process.

Data Migration and Import Options

What could better highlight the importance of data migration than the incident with Vodafone UK that caused the company to pay £4.6m in fine, which is the largest ever fine levied on a telecom firm for such reasons.

In 2016, telecom regulator Ofcom investigated the spike in consumer complaints against Vodafone. It found that Vodafone has failed to provide the services for which customers have already paid for. It was due to the botched data migration problem caused by the troubled CRM implementation.

In the build vs buy software analysis, data migration reflects two factors: one that you have to know whether the data migration tool the packaged software vendor is using is suitable for your requirements and second that if not, you may have to use additional tools, which would increase the cost.

Security

The onset of build vs. buy software brings another and one of the biggest concerns to the surface—security.

How compatible are the packaged software security systems with your organization’s security standards? How are the role, permissions, and hierarchy dynamics with respect to security? Do you enforce new tools for browsers or any other aspect of security?

With security—”nothing is safe until everything is secure.”

When tracking application security, ignoring any aspect, be it vulnerability in framework or other tools, irregular upgrades, or poor authentication implementation, could cause a security breach, which in turn lead to reputation damage and financial loss. But then any extra effort from your own end may lead to increased total cost of ownership.

3. Cost Considerations

Building digital capabilities is, by all means, a continuous journey with many milestones and no destination. The cost of a “journey” may increase with time but important here is that you be in a consistent quest to look for better alternatives.

As for your build vs. buy dilemma, here is a cost breakdown that includes critical junctions at which you have to shell out money. Check to see what works for your business the best.

Cost Types Build in-house Buy off-the-shelf

Upfront investment 800,000+ man-hours, 8 figure investments, potentially more* <1,000 hours evaluating the best software solution*

Hidden cost High: Increased chances of cost overruns, low productivity Minimal: low risk of delays, contracted pricing eliminates cost overruns

Ongoing cost Cost of service maintenance, data centers, security, and fully staffed IT group for feature request and bug fixes Minimal administrative support from the in-house team, and the future updates and new features generally included

Cost of innovations High: fully responsible to manage the updates of the software Minimal: flow with the industrial innovations

Opportunity cost Mostly, high because you lose out time building solutions. ROI gets affected by the constant investment in upkeep, innovation, compliance. Missed opportunity to use market-driven, compliant products. ROI is high and quick as product innovation is not individual responsibility and critical resources can focus on core tasks. Ability to explore a gamut of innovative solutions

Total cost of ownership Mostly High: Extensive cost to build a software from scratch, including a vast range of IT components. Low: Cost-effective SaaS, usage-based or similar models, pay when you need or pay for what you have used options available

Source: Deloitte

PS: An unwritten rule is that even if the cost of building a software is similar to cost of subscription for a let’s say 5 years of use, it never makes sense to build due to the other factors like maintenance, support, distraction and other factors.

We devised a comparison spreadsheet, available for download below, that further validates this theory.

4. Upgrades and Support

Consultation and support

If you follow the tech industry closely, you would come across incidents of bug fixes, security breaches, hacking and threats on a routine basis and even the big daddies of the industry face it from time to time.

For example, a bug in Virtua Health’s vaccine scheduling system caused somewhere 10,000 to 11,000, roughly 70% duplicate appointments. It took a 200 person team and 10,400 phone calls to finally fix the issue in the system.

Focus on what it took them to resolve the issue.

Would you be able to get this support if you find an issue with your system? Such issues are part of the software ecosystem and that is why consultation for maintenance, upgrades, and support are critical- be it via internal teams or having external infrastructure from people and other resources perspective.

Hiring and Training Staff

If you chose the build model, you would be competing with top companies in software development to bring the right people into the team. If you chose a buy model, you would be dependent on the people in top-tier companies.

In both cases, you are more dependent on the individual talent you are dealing with. While buying, in this case, brings some sort of relief that you will be heard by if not one then by another in the software vendor’s organization, but in-house development does not give you such preferences. You risk losing control and transparency and getting into dependencies on the development team which may prove to be very risky.

One of the fixes that might help you is instituting the RACI model. It works by defining:

R: Who is responsible
A: Who is accountable
C: Who should be consulted
I: Who should be informed

Whether you are buying or building the software, clearly defining and assigning reliable and skilled people for these roles would help you understand the deficiencies and risk landscape in time, so that you can take the right actions to make progress and mitigate the risks.

Upgrade

Generally, software vendors release hotfixes and upgrades anywhere between 1-12 months to improve the compatibility of the software. In some cases, vendors may discontinue providing support for previous versions.

But when you have created custom code or UI on top of those products, these upgrades would affect the functioning of your software. Besides, it is possible that major upgrades in UI or other features could reduce the user engagement with software in the long-run.

In this case, your build vs buy the software decision depends on having resources in place to ensure the stability of the version (upgraded or not), meanwhile also supporting you in change management efforts.

The Step Forward

On the build vs. buy software stage, a factor that plays the protagonist, in contrast, is:

When you build—Will you be able to meet the quality of off-the-shelf products, especially products that are constantly evolving and generally are top class to meet compliances and quality parameters? When you buy—Are you buying from the right software vendor; one that is reliable, financially stable, consistent, and has a proven track record of long and firm stay in the market?

Besides, your software is prone to market uncertainties. A simple breakthrough in science and technology or change in consumer behavior could turn your current product into a legacy system, even before you realize it.

Are you nimble or fast enough from technology and financial standpoints to change your course of your strategies and align them with the market forces?

Or

Would you like to share your burden of technology innovation with another vendor and rather focus on core competencies?

Got questions or need help with making a better decision? Feel free to write to us at info@fieldcircle.com and our team with 20+ years of experience and has been on both sides of the table i.e. bespoke development as well as off-the-shelf solutions, will be happy to help you make a more informed decision.

Compare Whether to Build or Buy

Free Download- Download this spreadsheet with a detailed comparison covering all the factors that go in build vs buy decision making.