To Build, Or To Buy? A Modern Product Manager’s Perspective On A Classic Problem

Engineering time is one of your company’s most valuable resources—and as a product manager, it’s on you to use it wisely. Chances are you’re already well versed in the classic build vs. buy dilemma, relying on quantifiable insights about your customers, product, and team to decide when to invest those precious engineering resources in a given project and when to buy and integrate a vendor solution instead. But the market for third-party software components and developer tools is now evolving so quickly that new challenges and nuances must be considered in the build vs. buy decision process. 

Reliable, cost-effective vendor solutions exist for a wider variety of functions than ever before, so it’s becoming the norm to buy most functionality outside of your organization’s core competencies. A telemedicine app provider is unlikely to sink resources into developing its own video calling and chat messaging technologies, for example, because the app’s value comes more from optimizing how these and other services are combined and delivered than from reinventing each component. And now, even features that you would’ve expected to build in-house five years ago can be integrated at a fraction of the cost. 

Here’s how today’s sharpest PMs are thinking about the classic build vs. buy dilemma, why they’re choosing vendor solutions more often than ever, and which red flags they’re watching out for with both options.

Estimating Cost Accurately   

It’s easy to fall into the trap of viewing a vendor solution as expensive because it’s an external purchase. Engineering time is already a line item in your budget, so using some of it to build out a feature feels like common sense. All it takes is a little subconscious bias to arrive at an overly optimistic estimate of total internal build cost and justify this option as cheaper in the long term than monthly SaaS payments. Then, a couple of months into the project, you realize it’s going way over budget—and on top of that, you’re going to have to compromise on some of the originally planned functionality, at least for now. 

To prevent this scenario, plan for the unplanned and make sure you’re not missing any hidden costs in your initial estimate. Not everything is going to go perfectly the first time—bugs, scaling issues, and other surprises are part of software development, and they should be part of your cost estimate, too. Your calculation for the time and cost to build in-house will depend on variables like developer salaries in your area, the backgrounds and levels of expertise available on your team, and the required use case(s) and feature depth of your product. Still, the basic methodology for the calculation should be consistent. The following formulas serve as a reference point to make sure you don’t overlook any hidden cost factors: 

Simplified In-House Build Cost 

=

Initial Build Cost [Development Labor + Infrastructure Over Expected Finite Time Period]

+

Maintenance & Scaling Cost [Initial Break-Fix & User Feedback Period as Usage Grows + Recurring Infrastructure Costs]

Simplified SaaS TCO 

=

Cost of Implementation [Customization + Integration]

+

Recurring Subscription Cost [Base Rate + Anticipated Overages + Premium Features]

+

Recurring Administrative / Maintenance Labor Cost

Spending $500 a month to save a sprint or two and get a product or critical feature to market is usually a no-brainer. But when evaluating any third-party product, be sure to understand the nuances of each vendor’s pricing structure. Rapid growth in active users, for example, can trigger overages. It’s important to work with the vendor to customize a plan that anticipates your needs and provides the most economical pricing structure for both the present and the future.

Realistic Timeline Planning    

You can think about the time a vendor solution saves in different terms—engineering time saved, accelerated time to market, and/or accelerated time to value. Will your product still be competitive if you build and launch a minimum viable feature in three to six months, then sort out bugs, scaling issues, and improvements after launch? Would it be more competitive if you launched a stable, high-performing version in two weeks?

On the flip side, you have to do enough research to understand how much time a given vendor solution is really going to save. You’ll need to gain familiarity with the category of products you’re evaluating and then go deeper with at least a handful of specific solutions. What would a given solution’s learning curve look like? How much integration work will it take? 

Predicting Competitive Differentiation 

Will the feature or product you’re evaluating differentiate your product from the competition, or is it just a practical component of a larger platform? Subscription billing systems and payment gateways are good examples: If you’re building a fintech product whose core value prop involves improving these processes, you may want to tackle an in-house build. But if you’re building out an e-commerce app whose main differentiator is better shipping fulfillment and logistics systems, just integrate a vendor’s payment system and never look back. 

The distinction isn’t always so obvious—at the end of the day, be honest with yourself about whether your internal build would genuinely innovate a new solution or rehash a problem that’s already been solved. Does your team have a disruptive idea to pursue, or does this project ultimately reinvent the wheel?

Evaluating Extensibility & Scalability 

Given the potential savings in time and cost, buying a turnkey solution can seem like the obvious choice. But not all vendor products are created equal. You have to be confident that those up-front cost savings won’t come back to bite you down the road. Will necessary customization be more of a burden than just developing the thing from scratch?

If you go with Vendor A instead of building your own solution, are you going to find yourself in a position six months later where you really need to expand the feature to accomplish X, but the vendor can’t support it? At that point, you’d need to either switch vendors—a waste of frustration and engineering time—or go back to square one and build a custom solution after all, which could take months. The key is often to look for highly extensible solutions designed with developer customization in mind.

Similar questions apply to scalability: Can the vendor solution in question handle anticipated growth while maintaining solid uptime? On the other hand, can you ensure that your internal build will be architected for scalability as well? Whether you choose to build or buy, you don’t want usage growth to force a massive rebuild of core components in the future.  

Weighing Dev Opportunity Cost 

Can you afford to suspend other engineering projects in order to build this feature? Consider the dev opportunity cost—the other potential new functionality that could be built in the same timeframe. Would projects closer to your core value prop deliver more promising returns? 

Remember that dev opportunity cost isn’t a one-time problem: Requirements will change over time, and competitors (or vendors) who offer similar functionality will continue to improve their products. An in-house build means continued diversion of at least some dev resources in order to keep up. SaaS providers, on the other hand, shoulder the burden of keeping things freshly updated and competitive.

Architecting for Reliability & Performance 

One major risk of in-house development is that even a massive investment of time and money can result in a feature that is buggy, only works intermittently, or doesn’t work at all. Critical performance features like speed and response time require a great deal of testing and optimization, and a cumbersome experience can turn users away. Infrastructure needs to be highly available with near-100% uptime, requiring 24/7 monitoring and a plan to fix any issues immediately. No solution will be perfect in this regard, but SaaS vendors tend to take responsibility for performance as part of their service agreements.

Managing Cross-Platform Development 

Engineering costs multiply when you need a consistent experience across web/desktop, iOS, Android and/or any other applicable platforms. Each platform presents its own unique challenges and requires a different developer skill set. Organizations that choose to build a feature in-house will need to invest equally in development across each of these platforms or risk delivering a disappointing and inconsistent experience on one or two of them. Enterprise-grade vendors should cover all major platforms, with a team of dedicated experts working on each. 

Assessing the Risk of Vendor Lock-In 

Conventional wisdom tells us to be wary of long-term vendor commitments, both technical and financial. An expensive multi-year contract can be difficult to cancel if the solution proves unsatisfactory or if priorities shift. Worse, a vendor’s decision to discontinue or drastically alter their product can force a rushed and technically challenging migration to a new product. At that point, you might wish you had chosen to build your own solution in the first place.

The risk of vendor lock-in is real, but many product managers fail to anticipate the similar or even worse problems that can occur when they’re locked into a flawed solution that was developed internally. If an in-house build becomes unwieldy or outdated or if key developers leave—perhaps the only developers who really understand how the product works—it can be even more difficult to migrate off your own in-house solution than from vendor to vendor. SaaS companies, at least, tend to build migration tools into their offerings, and many include implementation support with their contracts. 

Making a Confident Decision   

Faced with the build vs. buy dilemma more often than ever, and with so many constantly evolving factors to consider, it’s easy to feel overwhelmed. One way to build confidence is to remember that no solution should be treated as truly permanent—with the right strategy, you can mitigate some of the risk involved with either approach. When you build a feature in-house, make sure your code is well documented and the overall architecture will make sense to any skilled engineer outside of the original dev team. If you choose to buy a solution, make sure you trust the vendor’s financial footing and market stability and confirm its product is modular enough that migrating away from it in the future would not cause a catastrophic failure for your own product. Paired with these considerations, the analysis above should help to produce an exhaustive list of pros and cons to support a methodical, informed decision.