Build when the feature is your competitive advantage. Buy when it is table stakes. If authentication, payments, or email delivery are not your core product, using a third-party service lets your engineers focus on what actually differentiates your product.
The Decision Matrix
Score each feature on two dimensions: strategic importance (how central is this to your value proposition) and maintenance burden (how much ongoing work does it require).
| Low Maintenance | High Maintenance | |
|---|---|---|
| High Strategic Value | Build. This is your moat. | Build, but invest in automation. |
| Low Strategic Value | Buy. Not worth engineering time. | Buy. Definitely not worth it. |
The AI build vs buy tool walks you through this evaluation with specific criteria for your product.
Five Evaluation Criteria
When the matrix does not give you a clear answer, score the feature on these criteria:
1. Differentiation. Does building this in-house create a user experience that competitors using the same third-party tool cannot match? If yes, build. If the bought solution delivers an equivalent experience, buy.
2. Total cost of ownership. Compare the subscription cost of a vendor against the engineering salary cost of building and maintaining it. Include opportunity cost: what else could those engineers build? Most teams underestimate maintenance by 3-5x. Use the ROI calculator to model the financial comparison.
3. Time to market. A vendor gets you live in days or weeks. Building takes months. If speed matters (competitive pressure, customer commitment, market window), buy now and consider building later if the feature proves strategically important.
4. Data control. Some features involve sensitive data where giving a third party access creates risk (compliance, security, customer trust). Healthcare, finance, and government products often need to build in-house for data control reasons.
5. Integration depth. If the feature needs deep integration with your core product (shared data models, real-time events, custom UI), third-party tools often create more work than they save because you spend months fighting their API limitations.
Real-World Examples
Buy: Authentication. Auth0, Clerk, and similar services handle login, SSO, MFA, and session management better than 99% of in-house implementations. Building your own auth is a security liability unless authentication is literally your product.
Build: Core recommendation engine. If your product differentiates on personalized recommendations (like Spotify or Netflix), the algorithm is your moat. Using a generic recommendation API means every competitor has the same output quality.
Buy: Payments. Stripe handles PCI compliance, fraud detection, international payments, and tax calculation. Building this in-house would take a dedicated team of 5+ engineers for a year and still produce an inferior result.
Build: Custom analytics dashboard. If your users make decisions based on your analytics (like Amplitude or Mixpanel), the data visualization layer is core to your value. A white-labeled charting library does not deliver the same experience.
The product strategy guide covers how build-vs-buy decisions fit into your broader strategic framework.
When to Revisit
Review build-vs-buy decisions annually. What made sense to buy at 10 employees may be worth building at 100. Three triggers for revisiting:
- The vendor's pricing grows faster than your revenue (common with per-seat or per-event pricing)
- You hit a limitation in the vendor's API that blocks a key product initiative
- The feature has become strategically important since the original decision