Build vs. Buy

One of my good friends helped me to an epiphany as a software leader about 5 years ago. After a particularly gruelling growth experience going from 0 - 60 developers in a fast paced startup, he told me: the thing I wished I knew most before starting was how much deciding build vs. buy was the mark of an experienced software leader.

The learning here comes down to this: As a senior leader in software development in the context of a startup, your first question when the business needs to evolve should always be: how can I avoid building this? It's always the case that something that seems so obvious now should come as a revelation to me, but that's how we grow as technicians and humans.

Since this time, I’ve tried to apply his mantra to all of my ventures, sometimes with success, and sometimes with great failure. Let's explore these a little more.

It’s in my nature: I’m a genius at using a hammer. I find myself fortunate and grateful to be in a world surrounded by nails, never doubting that any problem I encounter can be reduced to one. It's not fair to reduce all software developers to this analogy but sadly the glove often fits and doesn't help us hitting our fingers more often than not.

To my fellow software developers, I submit the following: all software is debt. The most debt-free, slick and automated piece of code today is tomorrow’s monolith, spaghetti-riddled maintenance dog. Turnover is inevitable, your genius partner or junior software developer on your team will move on and leave the rest of your team clueless no matter how well you have automated testing or documentation. New code will slightly deviate from your carefully crafted norms, business priorities will prevent you from writing your test cases. Today’s version 1 library will be deprecated two years from now. Therefore rewrites are inevitable and they will always happen at the most inconvenient time.

Let me clarify, code is inevitable in business, low code movement aside, all but a few modern tech startups can avoid writing code to provide some kind of value to their users. The thesis of this article is simply that all code is tech debt, we just don’t know how yet.

Given this, do your future self a favour and only take on the debt that will give you the highest return. You can expend precious engineering bandwidth today to build something you’ll have to maintain or put that bandwidth to work on the most important problem and solve the scalability limits of 3rd party software you use to solve the other problems into the pile of future debt.

So how do you deliver the experience your customers need and only build software you must: enter low-code solutions. For most software developers this is anathema - we’ve all been there: there are security issues, there are privacy issues, the API isn’t great or barely works, the sales team promises 10 days to integrate and six months later it still doesn’t work. These are all realities when you choose to buy over building it yourself.

We have no choice, but to build true value, some code and therefore some debt is inevitable. Debt in this context is putting the future bandwidth of the engineering team in hock in order to get a short-term gain today.

There are many business realities out there. Some mature businesses aren’t planning to expand their software development bandwidth in the next few years. Some businesses aren’t in the software business at all and may not see solving a small problem now at the expense of a bigger problem later as a wise choice.

But if there is one thing that your typical VC-funded, early-stage startup has oodles of, it's a bright future with ever-expanding engineering teams. What they don’t have is a lot of bandwidth today. In this context the tradeoff is clear: you’ll have more bandwidth to deal with the tech debt of integrating low-code software today in the future than you have now to build the capabilities you can just buy.

Funded startups have the luxury of cash in hand, but sometimes you don’t have the option to buy. As with my earlier examples,  a good business and software leader will question the timing and the need for the technology at all. If it's inevitable then there is no choice but to develop in-house software that duplicates something off the shelf, then this is the only and right decision.

Buy is definitely not always the right solution to all problems. Integrating a third party is almost always harder than advertised and delivers less value than promised. Depending on your market, buy may not be an option for privacy, regulatory or reliability reasons. The experienced software leader knows this and discounts these risks in planning and decision-making. In the context where you are bandwidth-poor now and bandwidth-rich in the future: buy should always be your default.