Build vs buy decisions in the age of software abundance

Daniel Jarjoura -

I recently had a discussion with a tech leader on a build vs buy decision he had to make. He just joined a training company and has to revamp their IT toolbox. Since I know a thing or two about the topic (I designed a training management system at my previous startup), we started discussing the pros and cons of building your system vs all the other alternatives you have in 2020. Because let’s be honest, the duality of “build vs buy” doesn’t hold up at a time where bundled web applications, open-source components, hosted APIs and no-code development platforms can solve your users’ problem. In this essay, I’d like to propose a new build vs buy decision framework for the 2020 software era.

The age of software abundance

When I started my career in IT (yes, we didn’t call it “tech” at the time), technology leaders really had two alternatives when it came to solving problems with software. You either bought an expensive solution from an established vendor, like SAP or Oracle, or you built it yourself (or using an outsourcing company). And if you were an SMB, you were left off with usually crappy software or, if it existed, the light version of the expensive enterprise vendors. Today, the enterprise IT world is still dominated by this duality. SAP and Oracle still make tens of billions of revenue, and outsourcing companies like Accenture work with virtually every big company in the world. But, for the past ten years, the IT environment dramatically evolved.

Thanks to the democratisation of cloud computing, the increase of free development tools, and the appearance of easier-to-use programming languages, making software has become simple(r) and inexpensive. And when something is simple and inexpensive to make, it becomes abundant (or even overabundant). In just ten years, the B2B software landscape went from several actors to thousands, with some categories crowded with alternatives. There are, for example, 255 sales management tools showcased in the GetApp recommendation platform. And every day comes with hundreds of new software alternatives. There’s even a website to discover them.

And that’s not all. The applications have become more specialised to be more visible and bring even more value to users. For example, while SAP SuccessFactors provides a full HR management solution, companies like Lever, PayFit or Appraisd focus on one use case (recruitment, payroll and performance management); each solution being provided, of course, for a fraction of SAP’s price. And thanks to workflow automation platforms like Zapier, who take advantage of these solutions’ open APIs, you can create your own ERP by bundling multiple web applications together.

APIs & SDKs

But even with so many alternatives, sometimes the right software (or bundle) doesn’t exist. Or maybe it does, but you still want to build it (more on that below). Even in this case, there could be many build vs buy decisions to make. Like using an open-source component.

With over 100 million repositories on GitHub, long gone is the time where you had to browse Sourceforge for hours to find the right piece of code for your platform. There are now thousands of major open source projects to help developers ship features faster, some of them backed by the large tech companies like Google or Microsoft. And even then, you can still opt for a hosted (and paid) alternative that provides an SDK or API. Like, for example, choosing to use Algolia (paid) instead of Elasticsearch, Twilio (paid) instead of Somleng or Intercom instead of Chatwoot. The recent rise of “business-to-developer” startups (companies that sell an API or SDK) show that easiness of implementation, speed or 24/7 customer support, more than often beat the developer’s will to build its component.

To sum up, in the past ten years we went from a “simple” choice (build or buy one software) to a much bigger decision-making spectrum that involves multiple build vs buy decisions at the task or feature level. For every user story, you also have to decide between using a 3rd-party web application that solves this one problem, “renting” the feature using an external API or integrating an open-source component—the last resort is, of course, building it from scratch. When dealing with such complexity, simple 2x2 decision frameworks don’t work. You have to find another mental model.

Wardley Mapping

Developed by geneticist and former tech executive Simon Wardley, Wardley Mapping is a technique that helps you examine your environment, identify upcoming changes and correctly choose your actions. There are two main concepts in Wardley Mapping: value visibility and the four stages of technology evolution.

The initial idea is to break down the studied system into functional components, each component being needed for the previous one to work. Back to my Training Management System example, for the learning component to work, it needs a content management component, which needs a content hosting solution, which needs a database, which needs to be hosted on a server. Each of these components has a visible value for the end-user. The application itself has a very visible value because it’s the user interface, while the database and the servers are useful but not very visible. So, in the map, the higher the component, the more visible the value.

Classifying components by visibility is an excellent first step, but it’s not enough for a build vs buy decision. The second step is to identify at which stage of the technological evolution each component is. Wardley has identified four stages:

  • Genesis: this represents the unique, the very rare, the uncertain, the continually changing and the newly discovered
  • Custom built: this represents the very uncommon and that which we are still learning
  • Product (including rental): this represents the increasingly common, the manufactured through a repeatable process, the more defined, the better understood
  • Commodity (including utility): this represents scale and volume operations of production, the highly standardised, the defined, the fixed, the undifferentiated, the fit for a specific known purpose and repetition, repetition and more repetition

For example, when the Uber app came out, there were no existing alternatives to match customers and drivers in real-time → Genesis stage. The matching algorithms already existed but most certainly were adapted for this specific use case → Custom Built. The database that powers the app has been available for decades and has several open source and commercial alternatives → Product stage. The Cloud services hosting the whole thing (AWS) is now a commodity. As you can see in the picture above, most components of a Training Management System are in the product and commodity stages.

The last action is to use the map to make decisions.

As you can see in the picture above, you can decide to bundle 3rd-party products, buy a full-fledged product that does it all, or build part of the systems yourself. And if you decide to build, you can always do another map, with more granularity, to decide for each component whether you should build it from scratch, integrate an open-source component or rent an external API.

No-code

This post wouldn’t be complete without mentioning no-code and low-code platforms. In case you decided to go for the build option, you don’t necessarily need to have it done by a team of developers. Platforms like Faveod, Webflow and Bubble now allow what I call “software designers” to build a web application using visual programming. These platforms allow developers and non-developers to fast-forward the development of a web application using ready-to-use blocks like forms, buttons, databases, external APIs…

While many startups have used these platforms to build their MVPs and attract their first users, more and more companies never hire developers. Again, trying to decide whether you go for a no-code platform would depend a lot on the technological stage of what you’re trying to build. If I had to build a Training Management System from scratch today, I would go for a no-code platform.

In summary

  • The abundance of software choices makes build vs buy decisions much more complex to make in 2020
  • Technology leaders have now to decide between building a system from scratch, integrating open-source components, renting external APIs or SDKs, buying fully-fledged products and bundling multiple web applications
  • Wardley Mapping is a great tool to make decisions in a complex environment, taking into account visibility value and technology evolution
  • Even when looking to build a system, no-code tools can replace programming languages for speed and easiness to use

Additional resources

📝 SaaS: From Scarcity to Overabundance | Clement Vouillon

📖 Wardley Maps | Simon Wardley

📼 Investing in innovation - How situational awareness can put your business on the map | iluli by Mike Lamb