Build or Buy? Developer Productivity vs. Flexibility

By Charles Mahler / Use Cases, Developer
Jun 03, 2022

This article was originally published in The New Stack.

A common debate in software development focuses on whether to use already-available tools or services, which offer better developer productivity, or stick with lower-level tools or custom-built solutions, which offer more control and potentially better performance and flexibility. This can be boiled down to the decision of whether to build or buy.

These two approaches are at the root of many current tech industry ideological conflicts:

• Cloud vs. running your own hardware
• Using higher-level, dynamic programming languages vs. lower-level languages for app development
• Self-hosted vs. managed services
• Internal custom-built tools vs. off-the-shelf software-as-a-service solutions

Something as simple as the choice between using a client library as opposed to direct access via application programming interface when using developer tools illustrates the conflict. In this article, I will go over some of the factors to consider when choosing between client libraries versus using an API directly, using InfluxDB as an example. As we will see, this potential tradeoff of developer productivity and efficiency versus flexibility and control can be seen in other areas of software development as well.

The standard talking points

Here are some of the main points made by each side of the debate when it comes to building vs. buying.

Team Buy arguments:

• Allows more focus on core business.
• The team can move and add features faster.
• Prebuilt open source tools or specialized managed services, which are more efficient, offer cost savings.
• Hardware resources have become so cheap that developer time is more valuable, so improving developer productivity should be top priority.

The common argument against this is that this mindset led to “software eating the world.” Many older enterprises that saw software as a cost center that should be outsourced were eventually usurped by tech companies that took software seriously and saw it as a competitive advantage.

In defense of using prebuilt solutions, companies like Instagram and Dropbox (and many others) were early adopters of cloud services, which allowed them to focus more on product than infrastructure.

Team Build arguments:

• Removing service providers, which charge a premium, offers cost savings.
• Developing in-house expertise provides long-term benefits.
• Tools can be developed for company-specific needs compared to more general-purpose tools, which may lack flexibility.
• Fewer external dependencies, which could prevent outages or security issues.

The common argument against this side is that many tech companies’ value proposition to users isn’t about how their tech runs behind the scenes. Additional criticisms include advice to “not reinvent the wheel” and the diagnosis of Not Invented Here syndrome. The majority of users simply don’t care how things work behind the scenes; they just want the end result to work properly.

The flip side is that Amazon Web Services was able to develop as a business because of the in-house knowledge Amazon developed running its own services for its marketplace. This in-house knowledge eventually led to a trillion-dollar, cloud-computing market that revolutionized the tech industry. If Amazon had followed common wisdom and tried to outsource these operations, they wouldn’t be leading the cloud industry today.

Client libraries vs. API

To make things a bit more concrete, let’s look at a very simple example that shows the positives of both sides. Developers are the primary audience for InfluxData’s InfluxDB, a time series database. It provides both client libraries and direct access to the database via API to give developers an option that works best for their use case.

The client libraries provide best practices out of the box so developers can get started reading and writing data quickly. Things like batching requests, retrying failed requests and handling asynchronous requests are taken care of so the developer doesn’t have to think about them. Using the client libraries makes sense for developers looking to test InfluxDB or to quickly integrate it with their application for storing time series data.

On the other hand, developers who need more flexibility and control can choose to interact directly with InfluxDB’s API. Some companies have lengthy processes for adding external dependencies or already have existing internal libraries for handling communication between services, so the client libraries aren’t an option. There are many companies that have created their product as an extension or platform built on top of InfluxDB, which is made possible by the flexibility of the API. But that takes a bit more effort compared to using the client libraries.

On a micro-scale, using InfluxDB as an example, you can see that the best option will depend on the situation. For a company that is going to use InfluxDB to monitor its software or an adjacent task that isn’t a core part of its product, the client libraries make sense because they allow quick integration and developer productivity.

On the other hand, if a company is going to use InfluxDB as a core part of its product or needs more flexibility due to other circumstances, the API is available. By providing options, InfluxDB tries to provide developers with the best of both worlds.

There’s no single right answer

As much as people may want a definitive answer to these types of questions, the reality is that it comes down to each individual company and where they are as a business. The two major factors to consider are:

Is your software project critical to your core value as a business?

Is your business in a position, in terms of product-market fit, to try to gain an additional edge by building custom software?

For a startup still trying to find its product-market fit, speed is the most important factor and focusing on that makes more sense. For a company that is more established, building custom tools, making software more efficient or migrating to your own hardware can provide an advantage over competitors.