Read on Twitter
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 just as well #newessay #thread
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
Applications have become more specialised to be more visible and bring even more value to users. For example, while @successfactors provides a full HR management solution, companies like @Lever @PayFit or @appraisd focus on one use case (recruitment, payroll and performance)
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 togethe
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
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
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
Developed by geneticist and former tech executive @swardley 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
With the map, 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
And 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 @webflow and @bubble now allow what I call “software designers” to build a web application using visual programming
My full analysis here https://techleadership.substack.com/p/build-vs-buy-decisions-in-the-age">https://techleadership.substack.com/p/build-v... #end
