In your career, how many times have you heard your boss ask, “Can’t we just build something to solve this problem?”
Usually, this question comes with minimal understanding of how hard it is to build something, the lost productivity that comes with it, and the ongoing maintenance costs.
The data shows that buying software is usually the safe bet. According to Mendix, 54% of projects exceed their original budgets by almost 200%, and organizations cancel 31% of projects. Additionally, 3Pillar Global reported that the failure rate of building is two in every three projects.
Then again, many organizations have experienced the pain of buying software that promised to solve all of their problems only to find that the software didn't deliver enough value and became vaporware.
The reality: both sides have potential benefits and risks, and making the decision is rarely straightforward. But it is possible to make a build vs. buy decision you're confident in (and can get buy-in for) if you ask and answer the right questions.
Question 1: Is there a third-party solution that solves your problem?
Is the problem you're trying to solve something that's common to your industry, or is it something that's very niche and unique to your business? Before considering "build," look into the "buy" options and see what's available:
- Are there buyable tools that solve this problem 100%?
- Do those products do everything you need them to do?
- Are the things that existing products can't do must-haves or nice-to-haves?
- Do the vendors have the other things you want on their roadmaps?
If there isn't a product on the market that does everything you absolutely need it to do, the answer to the build vs. buy question is easy: you have to build it. But if there are options out there that meet your needs, you'll need to do some additional evaluating.
Question 2: Am I currently scaling people to solve this problem?
Growing the size of your organization to solve problems is a topic that is top of mind for many leaders. It's important to look at the people costs of building and maintaining a DIY solution when considering building or buying.
For example, if we look at demo engineering teams, some organizations have seven and eight figures of employment costs to build, manage, and maintain demo environments. Is that truly the best use of headcount?
Question 3: What are the costs of building versus buying?
This isn't as simple as comparing the development estimate to build to the annual subscription costs of a product. There are a lot of factors to consider when determining the real costs of building:
Upfront costs
What is the cost in people hours of building something from scratch? Do you have the team in place to build it, or will you need to hire to finish the build?
Maintenance costs
Few things are ever built once and perfect forever. The cost of maintaining a product is often much higher over the long run than the initial build. Consider the initial build time and the costs of ongoing maintenance.
Adjacent costs
If you build, will you need to invest in other technologies? What are the direct and indirect people costs that come with prioritizing the execution of this product? Include those costs in the estimate.
Question 4: What are the impacts of delaying in order to build?
Building takes much longer than buying, and long delays to solve your problem can also result in costs to your business.
Inaction costs
What risks might you run into if you delay solving the problem while you're building a solution? How much could you save by solving the problem sooner if you just bought a preexisting solution? Are you losing revenue by not having a solution in place sooner?
Split attention costs
What will you have to de-scope in order to free up capacity to focus on building a solution in-house? What does the decision put at risk?
Question 5: Are you confident you can build what you need?
The unfortunate reality of many build projects is that teams spend months or years trying to build a solution only to find that what was built didn't actually solve the problem, so they end up having to buy a solution anyway.
One of the reasons that I joined TestBox is that I spoke with a customer who spent over a year trying to solve a problem with a team of six folks. TestBox solved that problem in three weeks.
Question 6: Should you build and buy?
One potential compromise to the build vs. buy debate is to do both. You can buy for the short term and build for the long term.
This is much more costly but removes many of the build risks mentioned above — you don't delay solving the problem and can take more time to ensure what you build is exactly what you need.
Making the right decision
There's no simple answer to the build vs. buy debate. The right answer for your team and organization will always depend on what you need, what's available, what resources you have, and what you feel most confident in.
By answering the questions above, you can fully understand the benefits and risks of both decisions. And better yet, you can present those findings to executives in a comprehensive way that helps them fully understand the implications of the decision before it's made.
