Do you see the curvy pieces of wood in the trash bin? That’s a sampling of the templates I threw away as I was getting ready to build the custom desk I posted about recently. As a reminder, here’s a picture of what it looks like:

Getting the templates right was the hardest and most time consuming part of the project. I racked up at least forty hours on nights, weekends, and holidays designing, exporting, and cutting those parts. A solid twelve hours was spent just fighting with the software that controls my Shaper Origin, a CNC router. I cut the templates out four different times, and none of them were quite right. In the end, I decided to make up for my less than perfect templates with a whole lot of sanding. 

During this process, there were many times I thought I should just give up and buy a desk. I mean, the world is full of cool desks. What difference does it make to have another one, regardless of how cool it is or what it means to me?

This morning as I was walking my adorable dogs, I found myself thinking about the buy vs build decision, and I thought about how strange it is that we portray it as a distinct either/or decision and not a spectrum. In my career, this decision has rarely been that clear cut. Except for certain types of software, particularly desktop software, there is almost always a build component that comes with every decision to buy.

Let’s take my desk as an example. The materials, including the bits I ruined and threw away, cost less than $200. My time, though valuable, was free to me. I could make the case that it only cost me $200. And then I could make the case that buying this desk, or a desk as unique and cool as this, would easily cost ten times that or more.

But that’s disingenuous. Not because we are ignoring the value of my time, but because we’re ignoring the cost of my tools.

I won’t give you an exact figure on how much money I have dropped over the years to acquire all the tools I used to build this desk, but let’s just say it’s more than the cost of any car or truck I’ve ever owned.

And those tools, while expensive, were critical. Because I own a large set of capable tools, it is possible for me to build a desk like no other for $200. And now that I’ve worked out the kinks, I could build another one just like it in less than eight hours. Assuming I figure out how to make more accurate templates.

Now, I could skill up and make very precise templates with my Origin. Or I could find someone with a more traditional CNC and pay them to make those templates. Either way, whether through time or money, acquiring better templates is the key to doing this efficiently.

The decision to buy or build here isn’t that clear cut for me - I don’t want to be a furniture factory, cranking out 200 of these desks a day. I would like to build this particular desk again, just to see if I can improve the design, but it’s unlikely I would ever need those templates again after that.

Wait. That sounds like a clear “buy” to me. Just spend the money, get the templates, and get on with what really matters - building an awesome desk.

Except… I still wouldn’t be very good at using the Origin. And I need to be good at it, because I’m not going to stop building weird furniture with funky shapes. I want a whole library full of weird stuff - a cabinet that looks like the Tardis, a reading nook that looks like Bag End, a book shelf that looks like the Death Star. Building this skill is critical to what I want to do as a woodworker.

So it’s probably best to suck it up and build those templates myself, and put in the hours to be better at the Origin.

Here’s an important point about my desk. It wasn’t really a buy vs build decision at all. It was a “what do I want to buy, what do I want to build” decision.

Even if you decide you want to build a CRM rather than buy one, you’ve still got other things you will need to “buy”. You’ll need IDE’s. Open source libraries. Web application frameworks. Databases. Etc. You’re not going to build all those things, if your goal is to build a CRM. You’re going to buy them. (NOTE: we “buy” open source software when we add it to our projects - it may not cost you money, but it costs you, at the very least, compliance with the license)

The gist of all this rambling is that buy/build is a spectrum. There are very few times when we do a straight buy, and very few times when we do a pure build. Desktop software like Excel or Word is a great example of a straight buy, as are tools like VS Code, RubyMine, etc. These are the CNC routers of our world, and it makes sense to buy those and get good at using them.

At the other end of the spectrum, the pure builds, there is almost nothing, mostly just programming languages. Even those are built on top of other programming languages, compilers, etc. Almost nothing is ever built from scratch.

Most projects are somewhere in between, and almost always have a build and buy component to them.

For example, I was involved in a massive ERP implementation. We bought the ERP software, but then we spent more than $100M configuring it and integrating it with our other systems. Was that really a “buy” decision?

No. It was a “buy this and build that” decision. We couldn’t just buy the software in a vacuum and use it. We also had to build the ecosystem around it.

So how do you know which parts of your ecosystem you should buy and which parts you should build?

Over the years I’ve seen people apply lots of different criteria to these decisions, such as:

These are all valid metrics, but one I don’t hear enough about is the core skills and knowledge argument. And I don’t mean this from an engineering perspective - I mean it as an organization. If you asked my engineering team what our core skills are, they’d say something like this:

But that’s not really what I mean. The buy vs build decision shouldn’t be guided by questions like “can we do this with rails?”.

Instead, the question I would ask is this:

And then build that.

Now, as you build it, you might decide to buy certain parts of it. Salesforce. Sendgrid. Postgres. Containers. You might decide to build parts of it. The key is to think of the big picture and commit to building that. What you are trying to build should be your north star. It should guide everything you do.

Maybe that north star is something like “We’re building the best online leadership development experience on the planet.” Or maybe it’s “I’m building a library that channels my creativity and focus and celebrates the joy I find in making.”

Whatever it is, identify it. Write it down. Preach it to your organization. And then build it. Because if what you are about, what you are attempting to do, is something that anybody can go to the market and buy, you have already lost. 

Dave Christiansen
Writer. Maker. Programmer. Leader.