Build versus buy.
A few years ago I was working on a contract negotiation with Splunk, and we kept running into what felt like a pretty unreasonable pricing structure. They wanted some number of millions of dollars for a three year license, which felt like a high price to pay for thirty-two ascii characters in a particular sequence. Even with the license, we’d still be the ones operating it and paying for the capacity to run it.
We decided to negotiate by calculating the cost of running our own ELK Stack cluster, determined by means of the appropriate solution of solid numbers and hand waving. We used this calculation to establish Splunk’s value to us and ultimately got Splunk to come down to our calculated value instead of their fee structure, although I suspect we might have overpriced the value a bit and landed too high within the zone of possible agreement.
Recently Calm has been considering if we should move parts of our workflow to a headless CMSes, and consequently I’ve been thinking a bit more about how to make these sorts of build versus buy decisions, and in particular how to evaluate the “buy” aspect. Ultimately, I think it comes down to risk, value, and cost.
Risk
Using a vendor is taking on an outstanding debt. You know you will have to service that debt’s interest over time, and there’s a small chance that they might call the debt due at any point.
From a risk perspective, calling the debt due isn’t the vendor holding you hostage for a huge sum, although certainly if there’s little competition the risk of price increases is real. Rather, the most severe risks are the vendor going out of business, shifting their pricing in a way that’s incompatible with your usage, suffering a severe security breach that makes you decide to stop working with them, or canceling the business line (which some claim has undermined Google’s abiltiy to gain traction on new platforms).
Some risks can be managed through legal contracts. Other risks can be managed by purchasing insurance. Other sorts you simply have to decide whether they’re acceptable.
In the build versus buy decision, most companies put the majority of their energy into identifying risk, which has its place, but often culminates in a robust not invented here culture that robs the core business of attention. To avoid that fate, it’s important to spend at least as much time on the value that comes from buy decisions.
Value
Businesses succeed by selling something useful to their users. Work directly towards that end is core work, and all other work is auxiliary work. Well-run, efficiency-minded businesses generally allocate just enough resources to auxiliary work to avoid bottlenecks in their core work, reserving the majority of their resources for core work. This efficiency-obsession is a subtle mistake, because it treats auxiliary work as cost centers disconnected from value creation.
In reality, value is created by the overall system, which includes auxiliary work. Many companies create more value from their auxiliary work than their core work, for example a so-so product supported by extraordinary marketing efforts. Other companies sabotage their core work by underinvesting in the auxiliaries, for example a company of engineers eternally awaiting design guidance.
To calculate the value of a vendor, compare the vendor’s offering against what you’re willing to build today. The perfected internal tool will always be better than the vendor’s current offering, but you’re not going to build the perfected internal tool right now, what will you actually build?
Also, how will the quality and capabilities of the two approaches diverge over time? Most companies, particularly small ones, simply can’t rationally invest into improving their internal tools, such that they get worse over time relative to an active vendor. If you’re assuming the opposite, dig into those assumptions a bit. Vendors selling those internal tool have a totally different incentive structure than you do, and it’s an incentive structure that requires they make ongoing investments in their offering.
At a certain point you may reach your own internal economies of scale that support ongoing investment into internal tooling. Uber famously built their own replacement for both Greenhouse and Zendesk after reaching about 2,000 engineers, but they relied on vendors extensively up until they reached that point.
One way that folks sometimes discount vendors’ value to zero is they worry that the vendor simply won’t be good enough to use at all. This implies the existence of a boolean cutoff in quality between sufficient and insufficient quality. This is a rigid mindset that doesn’t reflect reality: quality is not boolean. There will be gaps in vendor functionality, and you should absolutely identify those gaps and understand the cost of addressing them, but avoid falling into a mindset that your requirements are fixed absolutes.
When it comes to build versus buy, the frequently repeated but rarely followed wisdom is good advice: if you’re a technology company, vendors usually generate significant value if they’re outside your company’s core competency; within your core competency, they generally slow you down.
Cost
Once you understand the value a vendor can bring, you then have to consider the costs. The key costs to consider are: integration, financial, operating and evolution.
Integration costs are your upfront costs before the vendor can start creating value. This is also the cost of replacing the vendor if the current vendor were to cease to exist at some point in the future. This is where most vendor discussions spend the majority of their time.
Financial costs are how much the contract costs, including projecting utilization over time to understand future costs. This is another area that usually gets a great deal of attention during vendor selection processes, but often with a bit too much emphasis on cost-cutting and not enough on value.
Operating costs are the cost of using the vendor, and in my experience are rarely fully considered. This includes things like vendor outages or degradations, as well as more nuanced issues like making mandatory integration upgrades as the vendor evolves their platform. Stripe’s Payment Intents API is far more powerful than the previous Charge API, but there’s a large gap between knowing a more powerful solution is available and learning last year that PSD2’s SCA requirements meant you had to upgrade to keep selling to buyers in the European Union.
How you want to use a vendor will shift over time, which makes evolution costs essential to consider, and similar to operating costs are an oft neglected consideration. This is where vendor architecture matters a great deal, and well-designed vendors shine. An example of good vendor architecture is headless CMSes: they’re flexible because they’re focused on facilitating one piece of the workflow. If some piece of the workflow doesn’t fit for a niche workflow you support, just cut that one piece away from the headless CMS: you don’t have to replace the entire thing at once.
Some vendor solutions try to create a crushing gravity that restricts efforts to move any component outside their ecosystem, and these are the vendors to avoid. Folks often focus on things like being vendor-agnostic, e.g. the ability to wholesail migrate from one vendor to another, when I think it’s usually more valuable to focus on being vendor-flexible: being able to move a subset of your work to a better suited tool.
Your total cost model should incorporate all of these costs, and becomes a particularly powerful tool in negotiating the contract.
Pulling it all together
Once you’ve thought through the value, risk and cost, then at some point you have to make a decision. My rule of thumb is to first understand if there are any sufficiently high risks that you simply can’t move forward. If the risks are acceptable, then perform a simple value versus cost calculation and accept the results!
Generally the two recurring themes I’ve seen derail this blindingly obvious approach are legal review (outsized emphasis on unlikely or mitigatable risks) and unfungible budgets (overall cheaper to use vendor, but company views headcount budget and vendor budgets as wholy distinct).
These are both sorts of bureaucratic scar tissue that accumulate from previous misteps, and aim to protect the business. On average, they likely are creating the right outcomes for the company, but for specific decisions they might not be. If you believe strongly enough that this is one of those exceptions, then ultimately I’ve found you need an executive sponsor to push it through.
A note on vendor management
Throwing in one more thought before wrapping this up, I’ve found that many companies are quite bad at vendor management and are quite good at building things. As such, their calculations always show that vendors are worse than building it themselves, and that’s probably true for them in their current state.
To get the full value from vendors, you have to invest in managing vendors well. A company that does this extraordinarily well is Amazon, who issue their vendors quarterly report cards grading their performance against the contract and expectations. Getting great results from vendors requires managing them. If you neglect them and get bad results, that’s on you.