How does HashiCorp think about building vs. buying software?

Transcript

Mitchell: The question of build or to buy comes up a lot. I think that our personality—being engineers, being the initial creators of all these tools—at least I very heavily leaned in the, "I can build anything" camp—hubris area—for many years. But building our own company here and seeing our customers has really enlightened to a lot of the really good reasons that buying is much better than building.

At HashiCorp, we have a need for a lot of software, and we tried to build a lot of it. We tried to build website deployment pipelines. We've tried to build some HR management software. We've done various things in the past, and what we've learned is that it's not what we want to do. We love building tools—our infrastructure-management tools—that's our passion. Every dollar that we were investing into an engineer working on something else was pulling away from us working on our core competency.

The other thing is that we just weren't doing it as well as someone else focusing on it full-time. We weren't getting dedicated support in the same way and we weren't thinking through the long-term maintenance of that thing. It's easy enough to build the initial version and get something working. Getting something working is not that hard, but getting something working that works indefinitely for your company, at high quality, and continuing to innovate and build features on top of it is really, really hard.

For us, our focus is on building really great tools for your infrastructure, for Cloud management, bare metal management, platform Kubernetes-type tooling. That's what you get from buying tooling from us. Your company could focus on exactly what your core competency is and what you want to work on.

Armon: Right, and I think maybe adding to that, especially given that the tools are open source, I think there's this sort of natural, "Why don't I just start with the tool. I'll make an internal copy of it and I'll add the capabilities and features that my company wants internally and we'll go down our own build journey." We've seen that happen with a few customers, but ultimately, they usually come back and realize that actually, the open source community is moving pretty quickly. There's all these hundreds or thousands of contributors, depending on the tool, that are actively adding features, fixing bugs, patching security issues, and all of that is coming upstream.

As they go their own way, they have this challenge of how do we, as a small team of two, four, six people, maintaining the custom version, keep up with not only the community but also HashiCorp, as we continue to add things there. So I think that becomes one challenge, is how do we try to keep pace with this, but the second thing is they end up quickly realizing, "Okay, we have this thing that we've home grown. There's two people at the company that know how it works, and support it. So what do we do long-term when those people are on vacation or leave the company?"

It puts you in this awkward position where you are no longer following the mainline of where the community is going, versus going with more of a buy strategy. It allows these organizations, as Mitchell said, to focus their engineering time and resources on their own core competencies, rather than the things we like to think are our core competencies. But allows them to keep pace with the community, pick up all those changes, get the security patches. And if they so choose, engage with us to have commercial support.

I think it's easy to overlook the long-term total cost of ownership when people start going down that path. They kind of only realize it a few months down the road of, "Okay, what did we actually sign up for here?! Those costs aren't visible, as Mitchell said, in that kind of initial working.

Mitchell: I think it really helps to have a concrete example in this scenario, and one of the most clear-cut examples we've had at our company was one customer who was looking at Vault Enterprise. And they specifically just wanted one feature of Vault Enterprise, which was the basic replication. And in their initial look at the product, they felt they could build this themselves, that they didn't need to buy from us. And we were okay with that, we sent them on their way, and they decided they'd reconvene about a year later to compare solutions basically. We'd give them a trial of Enterprise, they would use their own solution, and they would compare.

And when they came back a year later, they had definitely build a replication solution, and it worked. But what they found was ours seemed to work better, which even if it wasn't the case, there were all these other reasons they'd suddenly realized, which was that in the year since they had built it, we had built other features that they now needed. But they had to spend I think it was two or three people full-time for a year just to build out the initial replication feature, while we have a much larger team building multiple features in parallel to serve our enterprise customers.

And so they looked at our product, they saw replication working well, but then they also saw some other features that they needed to filter different secrets from different geographic regions, and some other access control features. And so it was one of those situations where you could plan and build what you want in a specific time frame, but it sort of puts on blinders to the parallel progress that's happening.

Armon: And I think ultimately that customer ended up going down the route of saying throw away our homegrown thing, go to the main line, and those engineers can go focus on adding value to the business itself.

Mitchell: Yep.