Editor's note: This article was originally published in February 2019. It has been updated in June 2020 with fresh content.
In 2014, Facebook announced they were building their own sales software internally.
Facebook's decision was a profound shift in direction away from the rest of the industry, and it sparked plenty of debate around whether companies should develop their own software solutions or subscribe to industry-standard tools like Salesforce.
These days, off-the-shelf solutions—many of which are available on a subscription basis, reducing upfront costs—are becoming more powerful, and users are demanding better, consumer-grade UX from their enterprise experiences. It's easier than ever for companies to purchase the right software for their needs.
At the same time, an ever-growing pool of talented designers and developers is allowing companies like Facebook to bring in resources to build custom solutions in-house. The decision is becoming less of “Can we make this?” and more “Should we make this?”
How to decide if your should build or buy software:
Sometimes the answer to "should we make this?" is a resounding yes: Building your own tool allows you to customize it and adapt it to your team's unique needs, rather than trying to adapt your team to a tool that was built for market. Because it's true that no ready-made solution is going to fit 100% of your criteria, 100% of the time.
But even with that said, the reality is that in most cases, buying a SaaS solution is almost always a safer and more efficient option than building a brand new tool. To determine if that's the case, you need to do 4 things:
- Figure out what you really need
- Calculate the complete cost of custom development
- Ask the right questions to assess pros and cons
- Assess the customer risks
Let's unpack each of those steps.
1. Figure out what you really need
It's easy to drive yourself (and your team) crazy trying to invent the perfect solution. Daniel Wolchonok, former Director of Product Analytics at HubSpot, explains that “ultimately...there’s no solution that will give you everything you need for every single analysis you have to do.” His own team spent years searching for the right product analytics system, building and scrapping a custom solution before eventually adopting Amplitude.
It's easy to get sucked into the trap of believing you'll be able to create a custom tool that entirely and singularly meets your complex needs and the needs of your customers. But remember, you created your business to solve a problem for your customers—as long as you continue providing value, how you solve that problem won't enter your customers' minds.
That's why it's important to consider the problem you're solving. Is the specific problem you're working to solve going to enhance the core value proposition you provide your customers? If not, and there's an existing product that meets your needs, then Peter Reinhardt of Segment recommends buying software whenever possible:
You should only be building your own tool if you've tried lots of others on the market and find that none of them will solve your problem. Only build if you’re left without a choice. And still take care: I’d estimate that 50% of the startups that I see build tools can’t maintain them.
2. Calculate the complete cost of custom development
Calculating the upfront investment you'll make to custom build new software is just the beginning. On top of the direct costs of buying or subscribing to an existing tool vs. developing a new product, you also need to consider the time-savings and opportunity costs that come with both options.
Our User Onboarding Cost Calculator can help you do some of that math:
Regardless of the size of your company or amount of talented on your team, your resources are finite—and you have to make careful decisions about how you utilize them. Building your own solution comes with plenty of opportunities for delays, bugs, security vulnerabilities, etc. The more issues you encounter, the more precious time and resources you tie up working to fix them.
The founder of Baremetrics, Josh Pigford, encounters that opportunity cost regularly:
Next thing you know, you’ve spent literally hundreds of hours building a tool that’s not core to your business. Hours that really hardly saved you any money. But worse than that, it was hours that weren’t spent making more money by improving your core product. Not only did you save an insignificant amount of cash, you actually stifled future cash.
One way to simplify cost comparisons between building and buying software is to compare the cost of the tool to the dollar value of your team's time. CEO Peter Reinhardt put this strategy into action at Segment, outlining his team's approach in his interview with First Round:
Tools not only save us money on hourly cost, but also accelerate our work. Say you are assessing your time at $50 per hour and buying MailChimp at $100 per month will save you building an e-mail distribution tool. That’s clearly worth it. So for us, it was getting disciplined about measuring the trade-off between our time and budget.
3. Ask the right questions to assess pros and cons
Regardless of which side of the debate you land on, both options are not without risks. To understand how the risks can affect your decision, ask yourself the following questions:
- What's the opportunity cost to the company if the project runs past the deadline?
- What happens to the tool if the people responsible for it leave the company?
- How reliable will our own solution be vs. an off-the-shelf tool?
- How much time will it take to train our team on either solution?
- Will the tool scale effectively to meet our needs?
That last point—scalability—is one that is often overlooked in the decision-making process but which often comes back to haunt a company's product team. Many CEOs and higher-ups underestimate how much maintenance and iteration is required to keep a tool running smoothly and scaling effectively—especially when that tool directly impacts the user experience, as is the case with user onboarding solutions.
Nancy Hensley, Chief Digital Officer for IBM Analytics stresses the importance of scalability in a recent AMA with GrowthHackers:
We have been taking some time to build better on-boarding experiences for our clients. This is critical for us in growth. We recently discovered a tool called Appcues that can help accelerate that process tremendously. I was very cautious about bringing this forward to our Dev and Design teams but we also need them to scale so anything we can do to optimize that would be great. Also, any tool that plugs into Segment give[s] us better insight and so that's really important.
4. Assess the customer risks of build vs. buy
Of course, off-the-shelf solutions aren't without risk. Be wary of any vendors pitching their software as plug-and-play—any time you introduce a piece of software into your critical path that you don't control, you're introducing risk. If you find a bug, you're relying on the vendor to resolve it quickly and efficiently.
You're also relying on SaaS vendors to manage data securely—you should always make sure the companies you buy from have the proper protections in place for managing sensitive information. Some things to look for: a SOC 2 audit, compliancy with PCI Data Security Standard and the GDPR, and comprehensive data isolation, encryption, and security breach policies.
Only build custom software when it gives you a competitive advantage
If custom software truly gives you a competitive advantage, then by all means, build. Sometimes, custom software can be the difference between offering a commoditized service and offering a unique customer experience. If the tool you're creating isn't already available on the market and will help create a competitive moat around your business, then your custom tool can be a great investment.
Compare Facebook's decision to build their sales tool with HubSpot's partnership with Amplitude. The team at HubSpot knew that product analytics was not a core competency of their business, leading them to partner with an existing vendor instead of creating their own solution. On the other hand, advertising sales is central to Facebook's business, and the massive scale of their business meant they were struggling to take advantage of existing tools; it made sense for them to invest in a custom solution.
But even after Facebook's decision to build a custom solution, Timothy Campos—the former CIO of Facebook who was responsible for their decision to develop their own sales tool—still prefers to buy tools instead of building:
I take the build vs. buy decision very seriously. Anything we build will have a maintenance cost in the future that has to be considered. Moreover, when you begin a project, the software that you are “going to build” always looks better than the software someone else already has because you haven’t yet run into the limitations that inevitably show up in software engineering. As such, we will buy wherever we can.
Always put your customers' needs first
For the vast majority of businesses, the risks and cost that come with building custom software consistently outweigh those of buying an existing tool. That's because the effort of creating and maintaining a tool in-house takes away time, energy, and development resources from improving your core product and serving your customers.
Peter Reinhardt of Segment sums up the problem well:
Many companies mistakenly build tools for themselves — instead of focusing entirely on their customers — because they understand themselves better than their customers. It's an easy trap.
Whether you're building new tools to giving advertisers a better customer experience like Facebook, leveraging existing analytics tools to better understand customer needs like HubSpot, or using third-party tools to help your development teams scale like IBM, the most important consideration when deciding whether to build or buy software is to keep your core product and value proposition in mind.
Build smarter, not harder: Avoid wasting time, money, and effort on building bespoke software that already exist as third-party solutions. And always put your customers' needs first.
