Build vs. Buy: you can save more than money

There’s no denying it: adding collaboration features adds value to your app. Not only have we discussed this at length, moves by Google, Salesforce, and Microsoft towards increasing collaboration features also validate this hypothesis. But if you’re not a multibillion dollar company you have to walk a delicate balance between expense and return. The more you spend, the more impact those expenses need to have on your revenue to make the expenditure worthwhile.

This balance leads companies to the inevitable question: do you build, or do you buy? Over the past year, we here at Weavy have conducted extensive research into the build vs buy dilemma. What we found is that the decision to build or buy features has a direct relationship with how much impact a company can expect to see from those features. There are a lot of hidden costs to be considered, and not all of them are financial. Put another way: the decision to build or to buy is nearly as important as the decision to add social collaboration features. 

Value and impact

It’s important to decide first how we define value and impact as discussed in this article. For value, we’re explicitly talking about the customer model of value. Rather than looking at your apps’ worth to the marketplace, you’re thinking about your apps' worth to customers. The two primary questions you should be asking yourself when valuing your app using the customer model are:

“How much value does my app generate for a customer?” And “What is the most a customer is willing to pay without feeling like the cost outstrips the benefits?”

For impact, this article is primarily concerned with the direct effect adding these features will have upon your app’s revenue. Collaboration features increase value by bringing an essential part of the user experience into your app. This increased engagement makes your app indispensable, increasing retention and thereby lowering churn. If features reduce churn by a measurable percentage, then that retained revenue will be considered the impact of that feature. 

Build vs. Buy isn’t cut and dry

Conventional wisdom has long held that building features in-house is a more cost effective approach than buying them from a third party vendor. At first glance this makes a great deal of sense: your product team already knows your app and how to iterate upon it, and they’re already on your payroll. But once you begin to peel away the layers, you begin to see that that line of thinking doesn’t always map to reality.

First is the old axiom that time is money. Collaboration features like in-app chat, document collaboration, and activity feeds are commodity features: they add value to your app, but they aren’t what makes it great. Time spent developing collaboration features is time your team isn’t spending on building core functionality and improvements. Your customers use your app to perform a specific job, and while adding collaboration features will help it do that job better in some ways, you’re essentially recreating work that third-party vendors have already done and may be neglecting the features that drew your customers in the first place.

You can of course staff up to double your output, and that’s the path that the Microsofts and Salesforces of the world are happy to do. At their revenue levels, the cost of a new team of developers is something closer to a rounding error than an expense. But for those of us still operating on planet Earth, it’s important to look at what those costs are.

Based on our own internal research and expertise in the field, we estimate that in order to build functionality commensurate with third party collaboration APIs you’re looking at at least six months of development time and an additional four months for UX development and user testing. To achieve this timeline we estimate that you would need a team composed of full time developers, at least one designer, and a product manager to oversee the development.

Assuming the industry standard monthly salaries, the cost to build, deploy, and maintain a full suite of collaboration features could easily enter the millions. Though you could argue this is money you would have already spent in operational costs, you have to take into consideration the time and attention taken away from your core features, as well as the ongoing maintenance costs should problems occur with your collaboration features.

Of course no two companies are the same, and your numbers may differ a lot or a little from our generic estimates. That’s why we’ve created a calculator so you can see just how much it would cost for your company to build collaboration features, as well as the impact you can expect to see. If you want to run the numbers yourself, click the link below. 

Let’s examine what it would cost to subscribe to the same Weavy tier that would give you these commodity features. For this comparison I’ve chosen Weavy for two primary reasons: it’s the product I’m most personally familiar with, and it has the most straightforward pricing model when compared to other providers. The cost to subscribe to the Weavy tier that gives users access to our full suite of collaboration features for one year is about $39,588. 

Now let’s go back to the time cost. What could your product team do with six additional months? They could iterate upon the features that make your app great, they could add new functionality that compliments those features, or they could spend time making quality of life improvements to the features they’ve already implemented. No matter which way you cut it the answer is the same: they’re doing work to differentiate your product in a crowded, competitive market. The money saved by buying commodity features pales compared to the gains that could be made by the time saved.

We’ve covered cost, we’ve discussed time. But what about the cost over time? Developing in-house is expensive to be sure, but it’s also largely a one-time expenditure, whereas continued access to a third-party API will require continuing to pay the subscription fee for the lifetime of your app. It’s true that eventually those costs will even out, but in several calculations it could take years or even decades before your subscription cost would add up to the cost of development. At the risk of sounding presumptuous, I believe taking a small loss after several decades of being in business is a pretty great problem to have. 

Assuming by now you’ve run the numbers it should already be evident that the value add of these new features will take considerably longer to offset the costs of developing in-house. This matter is only compounded by the fact that the nearly one year required to develop in-house is a year that your team won’t be working on differentiating your product. To make matters worse you won’t see the benefits of collaboration features such as increased user engagement and reduced customer churn, whereas buying functionality will begin to net results almost immediately. All of this while keeping your product team free to improve the core feature set.

Calculating the impact is both complex and incredibly subjective, requiring a robust understanding of customer acquisition costs, churn rate, monthly returning revenue and how many customers you have. Based on our own internal analysis, it takes on average about five years before the impact of building collaboration into your app measures up to the impact of buying the same functionality.

When it comes to adding functionality, product managers are often faced with a series of difficult decisions. When making those decisions it’s important to be mindful not only of the financial costs but of the temporal and logistical costs. When adding value for your customers and impact for your revenue you need to make the choices that extract the least value from your product team and make the least impact on your bank account.