The build, borrow or buy fractal
IT leaders are always going on about build, borrow or buy decisions. Seriously, they love it. It’s a key part of the language of doing software business.
Very few, if any, successful software products are 100% built in-house these days. Modern software is a complex orchestration of custom built (build), open source (borrow) and enterprise or *aaS (buy) code, systems and products. If a consumer product startup built its own custom web server software and data centre from scratch, we’d all laugh at them. And quite right.
Even a relatively simple SaaS app may consist of this stack, from bottom to top:
- AWS EC2 compute instances (buy)…
- running Node.js (borrow)…
- with Express and other libraries (borrow)…
- to build an API for business logic (custom)…
- using Auth0 for identity and authorisation (buy)…
- and SendGrid for sending email (buy)…
- with React.js and Redux on the front end (borrow)…
- used to create custom components and client application code (custom)…
And that’s only the tech. Software businesses think in similar terms for people, using a mixture of full-time permanent employees, freelancers and consultants, outsourcing and acquisition to get the job done in different ways for different reasons.
And it’s not just senior management that are making these decisions, unless they love extreme micromanagement. They happen every day throughout the company and at every level of the stack. The business of software is a fractal of build, borrow and buy decisions.
Take front end development. While a developer might identify themselves as someone who primarily develops custom-built code for a living, much of the job actually involves making or helping to make build, borrow or buy decisions, and then living with the ramifications.
We are making one of these decisions every time we add a new dependency rather than write a custom function, for example.
Some decisions are more important and more difficult than others. While it’s obvious that a two-person bootstrapped micro-SaaS shouldn’t choose to write their own database software from scratch, it’s not always so clear whether a team should use Bootstrap to get going, or write their own CSS library.
In a rapidly growing business, it’s almost impossible to make good decisions each time. We will and do make mistakes on a regular basis. Rational decision making is hugely overrated, because circumstances change quickly, and we’re not as good at the rational thing as we believe.
For me it’s better to optimise for being able to change our mind later than on making the one true correct decision. A decision should be informed by strategy, context, past experience and some lightweight research and experimentation in proportion to the impact the decision will have. But execution should be optimised for change or even reversal of that decision later on.
Next time you have a big build, borrow or buy decision, think about how you’ll be able to change your mind, and how costly that change will be.
Tell me about a build, borrow or buy decision that needed to be changed later. How hard was it to back out and replace?
All the best,
– Jim
