Solving Build vs Buy
A Developer’s Dilemma
Selling to developers is challenging, and the mindset of “build or buy” is one of the biggest hurdles. Over the past year at Mergify, we've encountered countless engineers grappling with this dilemma.
Developers are natural problem-solvers. When they encounter an issue, their first instinct is often to build a solution themselves. They see a problem, identify it, and immediately start imagining how they would solve it. However, there's a significant gap between having expertise in engineering and having expertise in a specific solution.
The Overconfidence Trap
Many developers fall into the trap of underestimating the complexity of the problems they're trying to solve. It's akin to asking an engineer, "How long to fix XYZ?" and hearing, "Should be done today," only for the task to stretch out over a week as unforeseen complications arise. They start working on the problem, only to discover layers of hidden challenges—refactoring needs, unexpected dependencies, and more. It all makes sense in hindsight, but it's nearly impossible to foresee these issues at the outset.
This overconfidence often leads to the creation of subpar solutions. While some teams might eventually succeed, these homegrown solutions fall short of their commercial counterparts more often than not. Moreover, solving problems outside of your core business usually results in a poor return on investment. Think about it: how many companies still manage their own email servers when GSuite offers a hassle-free solution for just $6 per user per month? Your IT team is incapable of competing with such an offer.
The typical customer for this comes to your demo call with a speech along those lines: “We’ve tried building a solution to this problem, but we failed because we hit too many bump roads; it seems you guys know how to solve it.” Teams that take this road are the easiest to win customers because they already know they can’t build.
The Build or Buy Mindset in Action
During our demo sessions at Mergify, we frequently encounter engineers who are initially skeptical about buying a solution. They come with a build-or-buy mindset, confident in their ability to solve the problem themselves. They're curious about why they should spend money on a product when they believe they can build it in-house. This is where it gets interesting.
One of the most enjoyable aspects of these sessions is debunking their assumptions. For instance, many engineers approach our merge queue system thinking, "This is just an automatic rebase, right?" After a 20-minute demo, they often leave with a new appreciation for the complexities involved. "Oh, okay. That sounds quite hard to do. Good job." This is where I reply with: “Well, this is why we’ve been working on this for 5 years already and have hundreds of customers.” 😉 Let me brag a bit.
By walking them through the numerous edge cases and intricacies that our product handles, we can show them just how challenging the problem really is.
The Power of Demonstrating Value
This experience highlights why startup founders who are engineers can be excellent salespeople. They understand the technical mindset and can effectively communicate the value of their products. The key is to convey the value of your product in your messaging and demos.
Having at least one feature that is both highly valuable and challenging to implement can make a significant impact. The more features like this you can demonstrate, the better—provided they solve real problems and aren't just complex for complexity's sake.
Final Thoughts
The "build or buy" dilemma is a significant barrier in marketing devtools. Developers' natural inclination to build solutions themselves can lead to underestimations of complexity and overconfidence. By demonstrating the intricate challenges your product solves and highlighting its value, you can shift their perspective. In the end, it's about showing that your solution is not just a convenience but a necessity for efficient and effective problem-solving.