Click here to Skip to main content
15,395,181 members
Articles / Editor
Article
Posted 31 Aug 2021

Stats

2.8K views
3 bookmarked

Build Versus Buy Software Decisions

Rate me:
Please Sign up or sign in to vote.
4.83/5 (3 votes)
31 Aug 2021CPOL5 min read
This article helps make a decision, whether to build a software feature in-house or buy a solution from a third party.

This article is a sponsored article. Articles such as these are intended to provide you with information on products and services that we consider useful and of value to developers

To make or to buy, that is the question. At least, it should be a question on every SaaS company’s mind. The build vs buy software equation comes into play when the relevant costs of building an in-house solution surpasses the perceived value of the feature.

It’s a constant calculation that requires monitoring, but the cost often flies under the radar until it becomes too big to ignore. The tendency in most organizations is to develop features whenever possible. This makes sense, of course, because your team knows the pains of your clientele better than anyone else and can customize the solution to their liking.

But when users demand a feature, but refuse to pay extra for it or when the feature is simply asking too much of your team or budget, the needle slowly tips to "buy".

What is a make versus buy decision?

A make or buy decision is the decision to build a software feature in-house or buy a solution from a third party.

In theory, this decision is simple. If the cost of buying a solution is less than the cost to make it, then it’s worth it, right? Oh, how we wish business math was that straightforward!

How to make a "make or buy" decision

The first complication is understanding which items to include when calculating the cost to make a product or feature. When you have an in-house team, it’s easy to forget the true spend. Here is a non-exhaustive checklist of potential expenditure:

  1. Research and product management = Estimated time to research x Cost of employee(s)
  2. Developer salary = Estimated time to build x Cost of employee(s)
  3. Maintenance costs = Days of maintenance per month x Cost of employee(s)
  4. Customer service salary = Time to answer tickets x Cost of employee(s)
  5. Overhead costs

The second complication is that these costs are predictions. Even the best estimates leave room for error. The project might be more complex than originally intended. Or the team might not be fully equipped to handle the intricacies of a feature that falls outside of their regular scope.

For that reason, risk needs to be taken into consideration. How many resources can be dedicated to an in-house solution without jeopardizing daily operations? What are the opportunity costs of investing resources to building this feature vs. a different feature?

On the other hand of the equation is the "buy" calculation. The biggest factors here are compatibility and customization. Even if a third party solution is more cost-effective, it may not be the best fit for your product or customer base. Before shopping for a ready-made software solution, consider the following:

  1. Which features are "must haves"?
  2. Which features are "nice to have"?
  3. Which features are "must not have"?
  4. What’s the maximum amount of set-up time required?
  5. How long will the solution serve our needs? Can it grow with the company?
  6. Will our users intuitively understand this software or will they require further onboarding?

When deciding whether to buy or build, the answer lies at the optimal point between cost-effectiveness, shipping features quickly and maintaining pace of day-to-day operations.

Make or buy decision example

AI-marketing company Samba.ai experienced both sides of the build versus buy decision when they realized their users needed a way to design customer-facing emails. Initially, they shipped their own email editor, thinking it would be a straightforward process.

But as their users demanded more from the tool, they encountered a dilemma. So many of their in-house developers were spending their time working on the editor that the development of their core product began to slow. What had originally been a cost-saving decision began to erode opportunities for growth.

After a closer look at their "build vs buy" calculation, they decided to look for a third party solution. Based on the needs of their users, they decided on the following stipulations:

Must haves:

  1. Quick implementation time. Since Samba.ai users were already using the email editor, they wanted a solution
  2. User-friendly interface.
  3. Customization options.

Nice to have:

  1. Strong customer support.
  2. Template catalogue.

Must not have:

  1. Anything that required advanced technical skills from the user. Samba.ai specifically searched for a no-code editor where users could drag & drop needed email elements.

After testing solutions, Samba.ai decided to embed BEE Plugin into their solution. Within 30 days, they released the new email editor to their customers and realigned their resources to go full-throttle with developing an AI marketing solution.

Let’s put it into numbers. Building an in-house email builder with the same capabilities as BEE Plugin would look something like this:

Image 1

Year 1 costs for in-house email builder

An average of over $1 million annually. And that’s just the start up costs. Maintenance costs would need to be considered, including a product manager, designer and team of developers.

Image 2

Maintenance costs for in-house email builder

That’s another 600 million USD in average. Bringing those together leads to an average total of USD$2.38 million over three years.

Image 3

Costs over 3 years for an in-house email builder

There are a few situations in which spending this amount would be justifiable.

  1. The email builder is core to the product.
  2. The email builder generates more revenue than it costs (through upselling or cross-selling).

Because neither of these were the case for Samba AI, embedding BEE Plugin at a fraction of the time and cost was the right decision.

Balancing "out of the box" solutions with customization

Perhaps the biggest question when choosing a third party solution is the flexibility to scale. The trade-off of a ready-made integration is that you don’t have control over the decisions that the other company makes.

As such, it’s crucial to choose a solution that not only has built-in customization options, but also a team that rises to meet the needs of your customers. BEE is proud to build relationships with our Plugin clients. When we choose which features to launch, we think about opportunities for you to delight your customers and grow revenue through customization options.

About BEE Plugin

BEE Plugin is the embeddable email & page builder for SaaS. BEE is a global team of over 50 people, half of whom work in Software Development or Product Management. Learn more about BEE Plugin.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Jules Costa
United States United States
No Biography provided

Comments and Discussions

 
-- There are no messages in this forum --