Build vs. buy: The integration challenge
Build vs. buy is just one of the dilemmas product leaders face. Leading a company’s product development efforts isn’t easy. As a product lead, you must produce the absolute best products and features for your current (and future) customers. As such, you must work with a variety of stakeholders in engineering, sales, and other functional groups. And as you know, that’s a bit easier said than done. This post will include a full build vs buy software analysis to help you understand the hidden costs of building and maintaining integrations in-house.
According to a global survey, the #1 challenge cited by 57% of product professionals is being “too tactical and not strategic enough.” In the same survey, the top two process challenges were along the same lines. The #1 top process challenge for product? Excessively focusing on the product dev and QA stages of a product’s lifecycle (while not focusing enough on pre- and post-launch planning). The #2 top process challenge for product: An overall lack of defined processes. (Yet in the same survey, product leaders predicted a potential 34% increase in their companies’ profits if they could just solve these issues.)
The most commonly-cited product challenge: Being too tactical. Image courtesy 280 Group.
In other words, the biggest challenge for product, as reported by those who work in product, tends to be too much of a focus on tactical, day-to-day tasks at the expense of higher-level strategy. And the majority of product professionals are convinced they can make a significantly higher contribution to the bottom line. Or they would...if they could just optimize their processes to get out of the weeds and focus on the bigger picture.
Our little story so far probably sounds familiar enough to you. But what’s really behind this challenge?
There’s never enough dev resources
Every company is different, and the challenges you face are likely unique to you, your organization, and your product line and its maturity. But for companies that offer technical products in particular, including Software as a Service (SaaS), there’s one common theme. The root cause that most directly affects product development is limited development resources.
According to a recent survey, the #1 most commonly cited challenge for software development is capacity - the ability to deliver working software despite facing an active backlog with limited development resources. 26% of survey respondents cited capacity as their biggest concern. However, in the same survey, the responses of two additional concerns - prioritizing development projects and time management - add up to 27%.
The most commonly-cited challenge for software development: Capacity. Image courtesy Coding Sans.
In other words, the issues of prioritizing dev projects and managing your engineers’ valuable time, taken together, actually outrank capacity as a development concern. But is this really surprising? Because development resources are scarce, it’s essential to deploy them in the best possible way. You need to maximize the time your engineering team spends on creating a better product that drives more revenue to the bottom line. You also need to minimize the time engineering spends on other projects that don’t contribute to product, or revenue in general.
Build vs. buy software development: A black hole of productivity
Now, let's not undersell the issue. Software integrations, which connect two or more software applications your company uses to exchange data and otherwise play nicely together, are critical. Consider the example of handing off qualified leads from marketing to sales. Specifically, your marketing team needs to integrate its marketing automation platform (MAP), such as Eloqua or Marketo, to the sales team's customer relationship management (CRM) platform, such as Salesforce or Microsoft Dynamics. As another example, your customer success team may need to integrate its support platform to payment processing software to update payment details. In this case, the integration might be between helpdesk software, like Zendesk, and a payment app such as Stripe or Recurly.
Here’s potentially the biggest problem in our build vs. buy analysis. While building these integrations helps with day-to-day operations, it doesn’t directly contribute to your company’s product, revenue, or strategy. Analyst firm Gartner reports that 90% of organizations “lack a postmodern application integration strategy and execution ability resulting in integration disorder, complexity and cost.” In other words, in-house integrations, being so low on the strategic totem pole, tend to become the opposite of a strategic project, often being poorly-planned, messy, and costly affairs.
Building a software integration in-house is a costly, multi-step process. Image courtesy DZone.com.
Exactly how much will it cost, and how long will it take, to build the average software integration in-house? As you might guess, there’s no one-size-fits-all answer to this question. Every integration is different and has different requirements. One estimate on the “average” cost of a custom software project clocks in at $40,000 to $250,000 at the low end.
However, this doesn't take into account the potential duration of an internal development project (to say nothing of the scope!). As a product lead, you know internal development is a multi-step process involving planning, scoping, designing, implementation, and testing, among other things. Some estimates suggest a duration of "anywhere from 1 to 6 months to get right...up to a year in some cases with larger projects," for internal development projects. Obviously, depending on the scope, in-house integration projects can take even longer.
And of course, there's the final step in the software development process: maintenance. After building a native integration between Zendesk and Stripe, your developers' work on that integration isn't over. Not unless Zendesk and Stripe never, ever update their software applications to a new version again. Of course they will! Unfortunately, any updates will likely break the integration your developers built in-house. As a result, your dev team will need to sink even more hours back into that particular integration. (And you'd have to multiply this process by however many internally-built integrations you currently maintain.)
Consider how expensive it is to hire, train, and keep engineers on board in this extremely competitive hiring market. You can do the cocktail-napkin math on "Annual Salary of Engineers" x "Number of Engineers" x "Project Duration," for instance. It should be easy to see how the actual cost for a development timeframe this long adds up to a very significant sum. Clearly, you'd be better off spending such a sum developing your company's product itself.
As it happens, enterprises and fast-growing businesses around the world are already coming to this conclusion...and they’re finding alternatives to building integrations in-house. Leading CRM Copper dramatically accelerated its integration velocity by opting not to build out integrations internally, focusing instead on enhancing its core product offering. Local business leader DexYP completed a 12-month internal integration project in weeks. Publishing powerhouse Vox Media sped up new customer onboarding 20x by bypassing an in-house integration build.
Interested in learning how you can save time, cost, and valuable development resources to deploy them towards strategic product goals instead? Get more info on how you can resolve the build vs. buy question by seamlessly adding integration and automation functionality to your software product.