Hungry for Insight
Published in

Hungry for Insight

Build vs. Buy — Make Your Decision Carefully

If you’re considering building a tool as opposed to paying for a third party product, you probably fall into one of two categories: a founder/co-founder of a scrappy startup with limited financial resources who can hack something together over the weekend; or you’re at a more established company that can spare dev time to work on said tool. In either case, you shouldn’t take the build vs. buy decision lightly— depending on the complexity of the solution you’re trying to build, paying for a product can oftentimes save you time and money in the long run.

Resources and Opportunity Cost

First, let’s touch on the concept of opportunity cost. If you’re unfamiliar with this concept, it’s essentially a way to quantify the cost of NOT doing something. When it comes to building a tool internally, the opportunity cost is measured by determining how the engineering resources could have been used had they not been dedicated to building an internal tool. As an example, let’s say you’re an engineer at a startup, and you spend 5 hours building an internal tool. The opportunity cost of that labor is 5 hours that could have been spent working on your product — a product that is likely your main source of income. In a world where resources are scarce, we have to make decisions about how to allocate resources, and if you allocate engineering time away from your main product, you run a higher risk of inflated opportunity costs.

Theoretically, the best way to determine whether to build or buy is to estimate how much time it would take to build the tool internally. This estimate would allow you to calculate the rough cost of building the tool and compare that with the cost of buying an outside solution. But as anyone involved in building software knows, estimating development timelines is very difficult. I marvel at engineers’ abilities to create seemingly out of thin air, but even they have difficulty scoping the time requirements of a project.

Source: Reddit

Customization of Software

Everyday we move closer to the peak of flexibility and customization in software. Technology makes it possible for SaaS companies to offer unique solutions to their customers. These custom solutions typically come at an extremely high cost, at least for now. But we’re seeing this customization trend continue, and soon we could see highly customizable software at all price points. If you choose to build a product in house, you’ll find yourself spending time maintaining or updating the software to fit your needs; in the next year or two you could see paid products offering the same level of customization, with none of the maintenance required on your end.

Consider also that some paid products will offer 80–90% of the functionality you need; in these instances, you have to ask yourself if building a similar product in house is worth the remaining 10–20%. You may even be able to get the job done by combining the functionality of multiple systems using a product like Zapier.

Build vs. Buy for Customer Feedback Research

Let’s consider a build vs. buy scenario for customer feedback research. Now, it’s obviously important to consider the complexity of your customer feedback process. If you’re a startup, you probably get most of your feedback through chat and email; organizing customer feedback data from those two sources isn’t going to be very difficult or time consuming. But once your business is more established, you’ll probably take in feedback from a bunch of different sources. B2C products can receive feedback through chats, emails, app store reviews, surveys, and tons of other channels. B2B products might also incorporate feedback from customer calls and their CRM notes. When you consider organizing feedback from all of these different sources, you begin to realize the scope of work required just to get all of your customer feedback in one place.

Now consider the actual reason for centralizing all of your feedback — you want to conduct research that will lead to meaningful insights and better experiences for your customers. In order to do meaningful research across all of your feedback channels, you’ll need to organize the data in a way that makes it easy to query — this is no small task. You’ll also want your query results to be sortable so you can find insights from different types of customers. Maybe you’ll need to build team sharing features into the system as well; or perhaps you’ll want to build data visualization modules. Once you start down the path of building a system in house, you can easily fall victim to the sunk cost fallacy and continue building out the product to the detriment of your business.

Building a system with all of these requirements would take an immense amount of time — we know, because we built it! Even if you built a similar system yourself, you would have to maintain it and build new integrations for each feedback channel you implement. If you’re a smaller operation that gets most of your feedback through chat and email, then you can probably get away with building this in-house. But if you’re dealing with higher volumes of feedback across multiple channels, the cost of building a customer research platform could get out of hand fast.

EnjoyHQ helps teams find insights ands build better products. Learn more here: https://getenjoyhq.com/

--

--

--

A community for product people leading change

Recommended from Medium

Consulting Firms and Enterprise Software Companies Are On A Collision Course

Is your business sellable?

Real Free Money.for Black Business

As European Insurtech Surges, Learnings from a Maturing First Wave

How to Start the Mastermind Group You Need

Top 3 NFT Drops on March 3rd

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Dylan Ortega

Dylan Ortega

More from Medium

The Power of the Guild: Unlocking Engagement for your Product

From the vision of a product to the MVP backlog

Emergent Friction in Product Development

Working in Product Management