Build vs. Buy: 5 Key Considerations

It’s an age-old debate. When it comes to delivering new technology solutions, should you build them in-house or buy them off the shelf?

While this classic conundrum is by no means a new one, it remains top of mind for teams large and small. Having worked with hundreds of brands—from the well-oiled enterprise to the agile innovator—we’ve seen firsthand just how important answering this question can be. And spoiler alert: There is no magic answer. And oftentimes, it’s not an either/or decision. The right choice might actually be to do a little bit of both.

At surface-level, the “Build vs. Buy” decision begs to be unpacked. After all, your team has unique goals, challenges, and skill sets in place. Knowing which path to go down requires you to take stock of your current situation and evaluate the options against multiple criteria. While there will be pros, cons, and trade-offs associated with either choice, putting a solid framework in place will position your team for success. So, where do you start and how will you decide?

Ultimately, making the right decision requires you to think through five key considerations:

1. The problem that’s being solved
2. The internal know-how
3. The costs
4. The timing
5. The desired flexibility

Let’s break down the overarching build vs. buy question by answering (you guessed it) some more nuanced questions.

1. The Problem That’s Being Solved

As with most decisions, it’s important to start by clearly defining and understanding the problem that you’re trying to solve. Conventional strategy will tell us to build technology solutions that solve core business problems and create differentiated competitive advantage. Everything else? Strongly consider buying.

Imagine a financial services company is looking to deliver software that automates the loan approval process. This kind of solution directly aligns with the business’s core competencies. And since delivering faster loans will likely make the core service offering more competitive in the market, this technology is something that should be built in-house.

Now let’s imagine the same company is looking to upgrade its HR portal to give employees more self-service functionality. Like most, it’s not in the business of providing HR management solutions. And since building this kind of functionality in-house would not create differentiated value, they should strongly consider buying off-the-shelf HR management software. Otherwise, they run the risk of redirecting essential resources to this project that are really needed to shore up the company’s central area of focus.

This same analogy can be applied to customer engagement. In today’s digital world, marketers from every industry and region need to find new ways to connect with their customers on a human level—whether that’s on mobile, web, email, or a wide array of additional channels. Even though companies could build basic functionality in-house (Firebase, SendGrid APIs, etc.), should they? And is basic really enough? Let’s keep digging.

2. The Internal Know-How

Before getting too far into the analysis, it’s important to be realistic about what’s possible. In today’s age, delivering (and supporting) software that meets requirements and rivals that of existing solutions is no small feat. It requires dedicated manpower equipped with specialized skills.

Let’s take something as seemingly straightforward as push notifications for example. Building a scalable system and intuitive interface that allows non-technical marketers to send these snippets of text and measure their impact actually requires a fair amount of work. It’s not enough to assign an engineer towards this project for a few weeks and expect great results.

• On the bandwidth front, you’ll need to free up a team of resources who have experience handling feature discovery, development, testing, documentation, training, ongoing maintenance, and any additional activities you deem necessary
• On the knowledge front, aside from the general product development, compliance, and training skills required, you’ll need engineers with working knowledge of the latest iOS, Android, web development standards
• On the support front, you’ll need to establish processes to handle bug-fixes, tackle new feature requests, and maintain compliance with ongoing operating system (they come every year without fail) and (less predictable but often massive) regulatory changes

Acquiring or freeing up the human capital required to build and maintain these kinds of solutions internally can be quite the challenge. It’s frankly one of the main reasons companies turn to a software provider. They can rest easy knowing there is a fully-staffed team of proven developers, designers, product managers, technical support, and customer-facing professionals who are solely focused on building and maintaining this solution that addresses their immediate needs while leaving room for future growth.

3. The Costs

Let’s talk dollars and cents. At the end of the day, one of the most important considerations will be the cost of the solution in question. Every team has a budget and success depends on staying within this budget. And yet, what many teams fail to consider are the hidden costs of technology.

When you think about off-the-shelf solutions, it’s much easier to balk at costs upfront since they are explicitly priced and packaged by the software provider. With internal builds, however, things get more blurry. Outside of the initial solution development and hosting costs, there are a number of costs that lurk beneath the surface.

To help you account for these situations (and avoid being caught by surprise), we’ve outlined some common hidden costs that teams face when building in-house.

• Technical debt: With a custom solution, you’re assuming ownership for the long-haul. This means factoring in time and money to handle any additional code changes, update the knowledge base and internal teams, and even wrestle with additional storage and infrastructural costs
• Time to value: Software development can be a time-consuming process. There is a cost associated with waiting until internal development is completed before end-users can begin using it. This also increases exponentially with the complexity of the solution that’s required.
• Opportunity cost: Last, but certainly not least, is the cost of what your team could have built in the time that was spent on this particular solution. Engineering time is a scarce commodity. If your engineers weren’t spending time building a system for marketers to send out personalized (or even batch and blast) messages, what could they be building? How could they drive the business forward?

4. The Timing

Next, consider timelines. Although basic in-house solutions can be built in a relatively short time frame, the reality is that large-scale custom development projects are typically prone to delays and overrun schedules. If your team is looking to accelerate time-to-launch, there’s no doubt an off-the-shelf solution will help you get up and running sooner. The impact here? Less time getting working functionality off the ground and more time spent customizing, fine-tuning, and achieving quick-wins.

One of the best ways you can get ahead of timelines (and set your project up for success) is to dedicate time early on for requirements gathering and cross-functional alignment. While it may not be the most exciting item on your to-do list, it will pay off in dividends. And you don’t always have to face it alone! Consider reaching out to a trusted partner to help zero in on your needs and integrate the right solution within the right time frame.

Working from this clear set of requirements will help prevent you from pushing dates further out and to the right. And you might just learn along the way that the best decision for your team isn’t as narrow-focused as you originally thought. It could mean building AND buying. For example, we’ve seen cases where teams decide that they can take care of the simple in-browser website messaging requirement on their own, but delivering email and mobile engagement fall completely outside of their skillset and bandwidth. Or teams who’ve started building proprietary machine learning recommendation algorithms, but need an already-built customer engagement platform to action on them. In both cases, the most time-effective option could in fact mean navigating both routes in parallel.

5. The Desired Flexibility

Lastly, making this decision is a bit of a balancing act. Your team has to focus on meeting present-day needs while also keeping an eye towards the future. More often than not, there will be an existing solution out there that supports your required use cases. What’s crucial here is that you not only check the boxes initially, but also consider the future impact of your decision.

Going the off-the-shelf route inevitably means forgoing a level of control. Aspects of the solution like uptime & performance, ease of integration, bug fixes, and the overarching product roadmap will now be at the hands (and keyboards) of the software provider.

On the flipside, if you’re worried about locking yourself in to a specific software provider, you may want to think again. Deciding to build internally doesn’t always translate to full-fledged flexibility and innovation. Engineering turnover, shifting priorities, and increasing complexity and technical debt may leave your teams feeling just as tied down to an in-house solution. And the switching costs may be even higher.

Feeling conflicted with all of these different trade-offs? Again, there is that final, enticing option on the table. Sometimes we can get so caught up in the either-or decision that we forget it is possible to have our cake and eat it too: Build AND buy. Buy an off-the-shelf solution to get up and running quickly and harness flexible interfaces, APIs, and webhooks to further build and innovate on top of that solution. This hybrid approach can be just the ticket for minimizing risk and maximizing value.

Final Thoughts

As with most major decisions, there is no clear winner to the “build vs. buy” debate at the start. Initial reactions like “we should buy this solution because it’s not core to our business” or “we can build it cheaper in-house” need to be properly vetted. By evaluating the options against the considerations above, your team will be able to confidently make the decision that’s best for you. And that doesn’t always mean choosing one option or the other! Sometimes that means taking aspects of each, blending them together, and choosing both.

At Braze, we want you to invest in a customer engagement solution that will meet your needs in the short and long-term. Our comprehensive platform and services were designed to help you accomplish your digital marketing use cases faster while giving your engineers the freedom to build what’s best for the business—whether that’s building additional capabilities on top of Braze or spending that time on new and improved core products.

If your team is deciding between building customer engagement functionality from scratch or buying it off-the-shelf, get in touch. We’ve coached brands of all sizes and industries through this exact decision and would be happy to help you, too.