“Should we buy this software or should we build it?” The build vs. buy software question is common and challenging for product managers, especially when considering mobile app feedback.
Balancing your company’s immediate needs with long-term goals is tricky. Managers deciding to build or buy tools for their team struggle with comparing apples to oranges.
In the case of software, the dilemma becomes increasingly difficult as most enterprise companies have the resources and talent in-house to build software. It thus becomes less a matter of “Can we do it?” and more a matter of “Should we do it?”
3rd party mobile SDKs are common
Commonly, the ‘build vs. buy’ dilemma comes to an abrupt end when companies are reluctant to integrate, or even forbid integrating with, third-party software development kits (SDKs) of any sort. This is almost always fallacious thinking as the vast majority of app publishers already work with a wide array of third-party tools for mobile app feedback.
In fact, the top 100 apps in the App Store average no fewer than 6.72 different SDK integrations. These cover a variety of functions from crash analytics to Facebook social logins to review management:
Third-party software often receives a bad spin. Portraying it as something foreign or invasive in an otherwise pure app. What it really comes down to is delegation.
Integrating third-party software avoids app pollution and doesn’t imply inability to solve problems with your code. It simply means you’ve chosen to delegate a specific business function to focus on your core app. You’ve chosen not to reinvent the wheel when more valuable work awaits.
To see if your app has integrated any SDKs, look at the eleven features shown in the chart above. If you’re using any sort of tool for analytics (e.g. Flurry, Google Analytics), monetization (e.g. Google Mobile Ads), or social integration (e.g. One-tap registration with Facebook), you’re already using third-party software for mobile app feedback. You’ve made the decision to delegate so that you can focus on what matters.
5 common considerations before you decide to build or buy
How you answer build or buy ultimately comes down to five common considerations:
- Time to market: Do you have an immediate need for the software, or do you have time to develop it in-house?
- Total cost of ownership: How much will the software cost to buy? To build?
- Features and functionality: How well do existing out-of-the-box solutions meet your needs?
- Knowledge and expertise: Do you possess the resources and expertise to make the software as good or better than current solutions?
- Core competencies: How central is the software to your business? What would you be giving up dedicating a team to its development and maintenance?
Let’s look at each consideration in-depth to help you make your decision.
1. Time to market
You can integrate most third-party software into your app in mere minutes, often with minimal to no technical resources. An in-house solution, on the other hand, can take a dedicated team months to develop. According to a VMWare survey of IT decision makers, the average medium-sized IT project took five months to complete, with 17% of respondents reporting average projects taking between 7-18 months.
To further complicate matters, large in-house IT projects are notorious for exceeding their expected timelines. McKinsey’s report found that 7% of large IT projects were delivered late.
While developers can create in-house solutions in a reasonable time period, they often exceed their planned timeline and budget. If you need an immediate solution to the problem the software will solve, buying third-party software will speed up deployment, ensure a faster reaction time, and give you the confidence of a guaranteed timeline.
2. Total cost of ownership
Next, ask yourself: Is it cheaper to build or buy this software? What about maintaining it?
With third-party software, you know exactly what your cost is upfront. It may have a fixed price, or it might vary based on seats or monthly active users. Either way, pricing should be transparent and predictable month-over-month.
This subscription replaces in-house maintenance costs, spreading expenses across numerous clients for regular maintenance. The result is almost always a lower upfront cost and a lower recurring cost when you opt for third-party.
For in-house solutions, pricing is rarely predictable. According to a McKinsey survey of IT executives, large IT projects run over budget 45% of the time, while delivering 56% less value than planned. The same study found that 17% of projects go so bad that they “threaten the existence of the company.”
Additionally, consider your opportunity costs: If you allocate existing resources to building and maintaining this software, what will you have to give up? Where are you taking resources away from?
Effective in-house solutions typically require a dedicated team, meaning you’ll have to permanently move developer talent away from current projects or hire additional hands. To assess your opportunity cost, consider the best use of that talent and where your top developers can have the highest impact.
3. Features and functionality
When evaluating out-of-the-box software, consider: How well do existing tools meet my needs?
With in-house solutions, you have unlimited flexibility to create a product that meets your goals. As we saw in prior research cited, however, this advantage can be deceiving. McKinsey reports that 56% of large IT projects fall short of their original vision, launching with sacrificed features and value. The Standish Group notes that project success rates inversely correlate with the complexity of their features, accounting for the 19% of projects that never reach the market.
Third-party software can limit customizability. You do, however, have the freedom to shop around and evaluate competing vendors on the basis of features and functionality to find the product that best meets your needs. Often, you can even try out software, through demos, trials, and proofs of concepts, at no risk. You might even be able to negotiate future features in your contract for a premium if you represent a significant portion of the third-party’s business.
There’s a case for both buying and building the software you need. Building in-house solutions gives you total flexibility over your product’s design but comes with the risk of a challenging execution. Buying software may require sacrificing some of your envisioned functionality but allows you the freedom to freely evaluate options to find the best available fit.
4. Knowledge and expertise
Ask yourself: Do I possess the resources and expertise to make the software better, or equally as good, than those solutions currently available?
With third-party software, you receive both the technology and the expertise. Most enterprise plans offer a dedicated customer success representative who can help you get the most out of the software. These on-staff experts know the art behind the science, having worked with clients of all sizes to pioneer best practices, and can work with you to create a personalized plan for success.
In-house solutions may have the technology down, but still see inferior results without the same level of subject matter expertise unless the software falls directly into the business’ core competency. Of course, companies can, and often do, hire experts on-staff for specific business functions. Doing so, however, greatly increases the project cost and true experts are few and far between—and those who do possess the required level of expertise are often already working for third-party tools.
To demonstrate the difference between the art and science of software, consider the example of push notifications. Strict OS requirements dictate that the basic technology (the science) remains largely the same regardless of which provider you use. The impact of this technology, however, varies greatly, depending on how you employ it (the art). Without the art, push notifications often come off as spammy or annoying and are the frequent reason people uninstall apps.
Developers don’t create great software in a vacuum. It’s the product of years of trial and iteration, of working with your stakeholders to co-design something that meets both your needs and the needs of your customers.
Unless the software in question relates directly to your core competency, building in-house means replacing years of iteration with assumptions. The product might get the job done, but you’ll miss out on the team of experts committed to your success that comes with most enterprise-level software subscriptions.
5. Core competencies
Finally, ask yourself: Is my core competency aligned with building great CEM software, such that it would be faster, cheaper, or more effective to build the software in-house?
If you can confidently answer “yes” to the question above, building the software you need in-house will be to your advantage.
If, however, you’re even a little uncertain, delegating the business function that software solves to a third-party can save you the future headaches and risk associated with software development. Buying a third-party isn’t a matter of weakness or defeat; it’s a matter of resource allocation. You’re making the decision to conserve your limited resources—time, money, and most importantly, talent—and investing those resources into areas with higher dividends: the core features of your app.
Wrapping up
In the end, only you can make the decision to buy or build the software you need. We hope this post helps you reach your decision with confidence by detailing each of the key points to consider when evaluating the ‘build vs. buy’ dilemma in the context of your business.
