Time to Rethink Build vs Buy

I believe the fear that led to the deployment of large amounts of resources and budgets to remediate Y2K, followed by the dot-com bubble bust, had an unintended consequence. Many enterprises became extremely conservative when it came to building products, and defaulted to buying off the shelf wherever possible. Today, many enterprise IT teams are more comfortable with the procurement process—managing RFI (request for information), RFP (request for proposal), bake offs, and creating exhaustive weighted scorecards with complex pivot tables rather than being able to anticipate customer needs and build something that will differentiate their business.

I am not suggesting that enterprise executives should favor the build. I have chosen to buy instead of build many times, including the global financial system, Human Capital Management (HCM) solution, Customer Relationship Management (CRM) tool, Ad Sales and Traffic system, and many others. I am simply challenging the notion to buy by default and build only as a last resort that many enterprises have fallen into.

In the era of the cloud, fundamentals of building have changed significantly in terms of cost, effort, and time. It’s time we re-examine some long-standing arguments and refresh the thinking on build vs. buy.

Buying Is Faster while Building Takes Forever

When you look closely, the clock generally starts when the implementation begins to prove that buying is faster. We often overlook months and sometimes years spent in requirement gathering, vendor assessments, gap analysis, demos, scorecards, negotiations, and procurement. Over my career, I have been part of at least three large “evaluations and assessments” that lasted over 12 months. In one case, our choice was between two vendor products in the marketplace, making it at least a 50% probability to get the decision “right” even if we had picked out the option randomly from a jar!

Many enterprises are adopting Agile, DevOps, and small decentralized teams that can build, test, and pivot quickly based on customer feedback. With the cloud, builders can immediately focus on high-value differentiated work, saving a lot of effort that in the past went into setting up and managing infrastructure that created no customer value. Serverless has especially help cut time to market significantly.

Our development team at A+E Networks once got that dreaded call on a Friday before a long weekend. The ask was to come up with a solution that would allow us to stream an internal, all-hands meeting globally in a secure manner by Tuesday. The team turned to AWS Lambda to build, test, and launch the internal portal over the weekend. The solution was scaled up to support hundreds of concurrent streams during the event and was scaled back down soon after that. That is agility. I doubt if we could have even gotten an NDA (non-disclosure agreement) signed in two days if we had pursued a buy option.

It Is Always Cheaper To Buy than To Build

The comparison is often made between the cost of licensing and maintenance for off-the-shelf products and the cost of building something entirely in-house. The in-house numbers generally include the 15% to 20% contingency buffer as a historical best practice. What is often overlooked is the cost of workarounds and band-aids that are bolted on to the off-the-shelf product to meet unique requirements of a particular implementation, the effort of integrating this solution with other enterprise products, the work required for data clean-up, and conversion.

Then there is the ongoing cost of aligning your business to the vendor’s upgrade cycles. This can be a massive effort because of all those custom bolt-ons that almost always show up even though most projects start with the stated goal of a “plain vanilla/out of the box” implementation. Weeks or months are spent testing and fixing broken integrations and customizations. This is one reason many enterprises often fall behind with their upgrades and accumulate significant technical debt in the process.

With the cloud, builders now have the ability to tap into purpose-built databases, advanced APIs, and pay as-you-go models with the flexibility to choose from a wide range of services. For example, our team at A+E migrated off a third-party, off-the-shelf reporting product by building a solution using cloud native services from database to application layer that ended up reducing our cost from several thousand a month to $5 per day while enhancing customer experience.

We Are Not Amazon (or insert name of a tech company) So We should Buy Not Build

I have heard this argument often across different industries. For example, since we are a media or an auto manufacturer, or a CPG company, we should invest in creating new content, or cars, or products rather than building software. This argument misses the point not only about the software, but technology in general. Having advanced and scalable technology products powering your business can help differentiate your core product. It can help you innovate faster to create that new piece of content or a car. It can bring efficiency through automation in reducing the cost to bring that core product to the market faster. In the digital economy though, technology is an enabler that can even open up new ways to distribute your products and services, and reach new markets and consumers that were out of reach before.

It is not about who you are but what you are trying to do that should drive the decision to build vs. buy.

Technology is no longer a back office function, but a differentiator to accelerate your business. The toolbox for the builder has not only become broader and deeper with the cloud, but builders also have access to specific purpose-built tools for the job. Operating and execution models with smaller decentralized teams, Agile, and DevOps have significantly shortened the speed to market while reducing the risk of large failed investments. It is time we revisit some key assumptions on build vs. buy.

– Ishit

@ishitv