Make the Tool? Or Buy the Tool?
‘Life as a Disaster’ tackles the eternal question
In this Post:
How to Flip Burgers
Selecting the Right Ingredients
Modeling the Choice
The Kink in Time
The Exponential Kinkening
The Most Reliable Version of the Future
Notes for Nerds
I had a conversation with a friend the other day who opined that selling software tools to architects is hard. Even where such tools represent quantum leaps in technology and productivity. My friend theorized that was because whenever you try to sell an architect a tool, they’ll invariably conclude that some commercially available tool couldn’t possibly accommodate the uniqueness of their practice, and they’d be better off just building their own. There's almost an instinctual rejection of the idea that some tool, developed by some outsider, could understand the nuances of their practice well enough to make something well-fitted to the firm's methods. And under no circumstances, would we consider altering our own methods of practice to accommodate the workings of some tool we just bought off the shelf. I couldn’t really argue with that.
The decision of whether to ‘Buy’ or ‘Build’ can get pretty heavy, as you scale up. A $20/month licensing fee doesn’t seem like much, until you multiply it by 500 employees, and then by another 20x to account for all the other apps and tools that the staff demands, and then forgets about two days after installation. That’s $240,000 a year in a profession with margins thinner than a McDonald’s Quarter Pounder.
The decision turns on a lot of variables you would expect: licensing costs, staff size, tool usage, etc. The most important variable, however, lives outside the firm. As it turns out, the timing of the innovation cycle - how much time do we expect to go by before the market releases a newer, better version of the tool – affects such a decision more dramatically than any of the other variables inside the firm.
How to Flip Burgers
If you’re facing a choice between building a tool to flip hamburgers (let’s call it Bespokematic), and the market currently offers a Burger-Flipomatic 900, you have a choice you can evaluate along a number of factors But you also have to consider what happens when the Burger-Flipomatic 901 comes out. Does it have new features that make the 900 model obsolete? Does it tower over your bespoke tool in performance? Has the price dropped?
A bespoke burger-flipper would be a lot better, because you could customize it around the way that you like burgers. On the other hand, if you just bought the Flipomatic 900, you could use it today, and would avoid all the time & expense associated with building one. Because you’re concerned about the future (you read this Substack, after all), you also have to consider the eventual arrival of the Flipomatic 901. Your Bespokematic might be better than the currently available commercial option, but when the 901 arrives, will that still be true (assuming the 901 is a meaningful improvement over the 900, obviously)?
If you’re going to consider that, you should also consider the Flipomatic 902 deluxe, and the 903 ultra, and the 90-n. This seems like an open invitation to get neurotic about the future, and if you have a big problem with that I, I’ll go ahead and assume this is your first visit to this Substack. So, welcome. But seriously, building a Bespokematic is a considerable investment of time & energy – will it be worth it in the near future? The far future? At what version of the Flipomatic will it have improved enough that it’s actually the better option? How does one even start to consider a decision like that? One sleepless night, I decided to figure it out:
Selecting the Right Ingredients
Using a mix of Python, Excel and Claude 3.7, I built a decision model. I thought it would be easy enough to isolate all the variables that went into such a decision, quantify them (however clumsily) and develop a formula, of sorts, for calculating the 'right' decision to make in any ‘Buy’ vs. ‘Build’ scenario. Yes, I see the irony of building a custom model to figure out whether to build custom tools, rather than just take some expert’s word for it. Feel free laugh about me in the comments.
I sat down and made a list of everything that could possibly influence a ‘Buy’ vs. ‘Build’ decision. The only caveat I gave myself was that the variables needed to be general enough that they would apply generically to a ‘Buy vs. Build’ decision - and not be dependent on a very particular project, or project type, or client, etc. I wanted the model to be scale-independent, meaning, that it would compare the relative merits of ‘Buy’ vs. ‘Build’ for any particular tool, at any particular firm, without muddying the merits of a ‘Buy’ decision at a small firm with the costs of a ‘Build’ decision at a large firm.
As you would expect, there were a lot of variables – and they all had effects on each other. It was a classic multi-variable optimization problem. How does one maximize for the whole effort, knowing that adjusting any particular variable shifts the effects had by others? In that way, it was a lot like designing a building. One cannot 'optimize' for the section while ignoring the elevation. Nor can one 'optimize' for the interior while ignoring the exterior. A designer must move everything forward at once.
I then put the decision model through a Monte Carlo modeler, which is great for multi-variable optimization, because you can vary every variable at once, and generate thousands of scenarios to see how they behave.
It also gave me a control knob that I had been concerned about: I built the model so that I could alter the time horizon of the simulation. Meaning, some decisions are the ‘right’ one in the mid-term, but the wrong one in the longer term – it all depends on when you choose to evaluate it.
Modeling the Choice
I set my model to run 1000 scenarios at a time, to see how various ‘Buy’ and ‘Build’ scenarios would work out. That would be difficult to visualize, so I’ve included 16 of the ‘Buy’ scenarios (in red) and 16 of the ‘Build’ Scenarios (in blue) below. You get the idea. Despite their individual variations, they follow a consistent logic:
For all Scenarios, a dip in the early phase (where the tool is being built, or bought and subsequently onboarded).
The ‘Build’ scenarios have a dip that’s generally longer, later and deeper than the ‘Buy’ scenarios, because it takes longer to build a tool than it does to purchase one.
Both types of scenarios level off at some point (the point at which they’re fully adopted within the firm) and from thereafter, make steady contributions to the overall value of the firm’s work.
We can also take the difference between each blue curve and each red curve and generate a similar map of the relative value of the ‘Buy’ decision over the ‘Build’ decision:
At a casual glance, it might look like the ‘Buy’ Decision is always better, which had been my impression all along. But we can also see that the green lines are all descending in every scenario – this tells us that the value of the ‘Buy’ decision is declining steadily – approaching, and passing, zero.
That, in turn, tells us that in the long term, the value of the ‘Buy’ decision is negative. In other words, over the long term, the value of the ‘Build’ decision is positive, meaning that building the Bespokematic is the better option, in the long term.
That fits with our intuition, too. Presumably, if you build something, you’re building it to your own specifications. It’s a better fit, and therefore more useful, than commercially available options. So the incremental daily value resulting from building the Bespokematic (b) should be higher than the incremental daily value we get from buying the Flipomatic (f).
If that’s true, then it means that over time, the total cumulative value of the ‘Build’ decision is going to overtake that of the ‘Buy’ decision.
The Kink in Time
However, the model still seemed a little limited. It was only really telling us a few things we could have guessed:
Buying things is usually easier and faster in the short term
Building your own equivalent usually takes longer, and more expensive, but provides superior value in the long term.
What about INNOVATION? What about the relentless march of technological progress that renders today's miracle tomorrow's punchline? We expect some newer version of the Flipomatic to come out, and we expect it to be better than the last one. So I introduced two new variables:
(I) = the Innovation Cycle
the length of time elapsed between subsequent versions of the commercial tool. E.g. the time distance between the release of the Flipomatic 900, the 901, the 902, etc.
(S) = the Technology improvement
the amount of improvement we see between the Flipomatic 900 and the Flipomatic 901. Is it just shinier? Does it flip 2% more burgers? Do your taxes?
Including these variables shows up like a kink in the previous graph:
The Flipomatic 901’s superior value, over the Flipomatic 900, shows up as a kink but doesn’t alter the overall trajectory of the curve. No, not that kind of kink. Just a mathematical inflection – a jiggle in the red lines. But the red lines eventually converge on the blue because, ultimately, the Bespokematic’s superior fit with the firm’s operations means that it can provide superior ongoing value, even against the 901.
The ‘kink’ doesn’t avoid this eventuality, it just delays it.
OK, but what if there are multiple kinks? No, still not that kind of kink, and also still probably doesn’t matter, as long as the enhanced value brought by the technological improvement (S) is still less than that brought by the customization that ‘Build’ entails:
How do we know that (S) + (f) is always going to be greater than (b)? That would imply that Silicon Valley is always making steady (and meaningful) improvements to their products, which we know isn’t true.
The Exponential Kinkening
However, we can make a reliable guess about the long term improvements of technology, because technology always improves over the long term. If technology always improves over the long term, then S isn’t really constant . . . it’s growing with every subsequent release.
We can also infer from long term technology trends that the Innovation Cycle gets shorter over time – because technology is always speeding up.
So I introduced two new variables:
(ΔS): the increment of (S)
Instead of each new Flipomatic being 10% better than the last, each subsequent version of the Flipomatic would improve by 10%, 11%, 12%, 13%, 14%, . . . . over it’s predecessor.
(δ): the decrement of the Innovation Cycle (I)
Instead of a new Flipomatic coming out every 26 weeks, new Flipomatics would be coming out at time = (I0) – (n * δ). In other words, after 26, 21, 17, 13, 11 weeks, . . . until they’re coming so fast that the Flipomatic 977 is released before the Flipomatic 976 accidentally, destroying the fabric of time and space.
The Most Reliable Version of the Future
That led to a very different insight:
In most cases (again, it’s hard to depict 1000 scenarios clearly in this format, so I’m just using 1 as an example):
The Buy option was the obvious early favorite
The Build option would typically start to narrow the gap, perhaps even surpassing the Buy option
Until the Buy option pulled away – its curve drawn upward by the relentless acceleration of technology.
So what's the answer? What should you DO? Should you BUY or should you BUILD?
The better question is probably ‘how much do I care about the future, and which future do I care about? It depends on WHEN you're asking the question.
SHORT TERM (like, this-quarter short):
BUY the Burger-Flipomatic 900. It works today. Your quarterly report will thank you.
MEDIUM TERM (next year or two):
Maybe BUILD your Bespokematic. For a brief, shining moment, you will have the PERFECT burger-flipping apparatus, custom-tailored to your SPECIAL needs.
LONG TERM (after two years, or the heat death of the universe, whichever comes first):
BUY, BUY, BUY. Because no matter how SPECIAL you think you are, you cannot outrun the exponential curve of technological progress. There are more smart people outside your company than inside it, and they are all working while you sleep – not just to make the next Flipomatic, but to overturn your entire conception of how burgers might be flipped.
Notes for Nerds
To try and unravel the ‘Make’ vs. ‘Buy’ debate, I deliberately over-simplified some of the dimensions of such a choice.
Integration, for one thing. There’s a cost to having 20 different tools, all made by different software developers, all trying to work together. There’s a cost in dollars, and there’s a cost in frustration. A good CTO will make sure that tools used at the firm integrate well with one another. This was not modeled.
Vendor Quality / Credibility: Having a great vendor can make all the difference, when you’re buying any kind of software. A great vendor will be there when things break down, or when you need customizations. A legitimate concern nowadays, with all these new startups popping up, is whether or not certain companies will even be around in a few years. This was not modeled.
Timeframes, Units. Careful readers will notice that I did not append actual dollar figures to most of these calculations, nor did I specify ‘timeframes’ in any deep way. This is in order to avoid apples to llamas comparisons between very different scenarios that would have made the exercise useless.
Imagine a small 3 person firm is considering adopting a minor widget that will summarize meeting minutes, and that the cumulative value of ‘Buy over Build’ at 6 months might range from $5k to $30k, with a median value of $20k. Let’s also suppose that a 500 person firm is considering adopting a Revit-replacement firmwide, and that the cumulative value at 6 months, for them, might be between $1M and $6M, with a median value of $4M.
If we’re trying to model the merits of ‘Buy’ over ‘Build’, and I told you that the range of all scenarios was between $5k and $6M, that would be mathematically true, but that’s not really helpful information, is it? Similarly, if I told you that the average median value between the two scenarios was $2,010,000, that would be accurate, but actually misleading from the vantage point of either firm.
My model accounts for these kinds of distinctions. Meaning, if you input a small firm, and a small tool, it will give you a small result. If you input a big firm, and big tool, it will give you a big result. But it normalizes those results to achieve an apples to apples comparison of only the relative merits of a Buy vs. Build decision. The ‘spaghetti bowl’ of red and blue lines in the graphs above may therefore be considered independent of scale – either the scale of the firm, or the scale of the tool. The same patterns emerge, regardless of scale.
I don’t intend to publish the model itself (although contact me if you’re interested), but the critical variables are listed below:
FIRM VARIABLES (Fixed Across All Potential Tools)
Average Hourly Pay Rate of Tool User ($)
Average Hourly pay Rate of Tool Builder ($)
Time Allocation of Builder (As a percentage of their whole workload, how much time does the tool builder have to allocate to the making of this tool, while still keeping their other duties at the firm fulfilled?) (%)
TOOL VARIABLES (Varies Depending on the Tool Being Evaluated)
No. of Eventual Tool Users
No. of Tool Builders
No. of Task Executions per Tool User, Per Day
Time Saved by Adopting Tool, per Task (mins)
Realistic Adoption Rate (%)
Total Time Needed to Make In-House Bespoke Tool (hrs)
Total Time Needed to Deploy Commercial Tool (e.g. once the Commercial Tool is purchased, or the contract signed, how long does it take to get it loaded on everyone's computer and get them using it?) (days)
Monthly Licensing Cost for Commercial Tool, per User, per Month ($)