Every Capability Is a Make-or-Buy Decision
Product leaders make build-vs-buy decisions constantly. Should we build our own analytics pipeline or use Amplitude? Should we build authentication or use Auth0? Should we build a payments system or use Stripe? Should we partner with a data provider or build our own dataset?
The classic "build vs buy" framing misses a third option that's increasingly important: partnerships. Partnering means integrating with another company's capability in a way that goes beyond a vendor relationship. It involves shared incentives, co-development, or mutual distribution.
This comparison provides a decision framework for all three options. For the two-option version focused on software, see the build vs buy comparison. For AI-specific build decisions, the RAG vs fine-tuning comparison covers the technical tradeoffs.
Quick Comparison
| Dimension | Build | Buy | Partner |
|---|---|---|---|
| Time to market | 3-12 months | Days to weeks | 1-3 months |
| Upfront cost | High (engineering time) | Low to moderate (subscription) | Moderate (integration + legal) |
| Ongoing cost | 20-30% of build cost/year | Vendor fee (scales with usage) | Integration maintenance + rev share |
| Control | Full | Limited (vendor's roadmap) | Shared (negotiated terms) |
| Customization | Unlimited | Constrained by vendor features | Negotiable but limited |
| Maintenance burden | You own it (security, scaling, bugs) | Vendor handles it | Shared (your integration, their product) |
| Risk profile | Execution risk (can your team build it?) | Dependency risk (vendor outage, pricing) | Relationship risk (partner pivots) |
| Best for | Core differentiators, unique needs | Commodity infrastructure | Domain expertise, market access |
| Switching cost | Low (you own the code) | Moderate to high (data migration) | High (relationship + integration) |
| Scale behavior | Marginal cost approaches zero | Cost scales with usage | Depends on agreement terms |
Build. Deep Dive
Building in-house means your engineering team develops and maintains the capability. You own the code, the data, the infrastructure, and the roadmap.
When Building Wins
Core product differentiators. If the capability is what makes your product unique, build it. Spotify's recommendation algorithm, Stripe's payment routing logic, and Figma's real-time collaboration engine are all built in-house because they are the product. No vendor solution would provide the same competitive advantage.
Unique requirements. When no vendor solution fits your use case, building is the only option. This happens in regulated industries (custom compliance workflows), niche markets (domain-specific algorithms), or bleeding-edge technology (novel ML models).
Long-term cost optimization. At scale, in-house systems cost less per unit than vendor solutions. Stripe charges 2.9% + $0.30 per transaction. If you process $100M/year, that's $3.2M in Stripe fees. Building your own payment processing (which very few companies should do) costs $1-2M upfront plus $500K/year in maintenance. The breakeven is around $50M in annual volume. Most companies never reach the volume where building is cheaper, but those that do save significantly.
Data ownership and privacy. When customer data sensitivity requires full control over storage, processing, and access, building keeps data within your infrastructure. This matters for healthcare (HIPAA), finance (SOX, PCI-DSS), and government (FedRAMP) applications.
The True Cost of Building
Teams routinely underestimate build costs by 2-3x. A realistic cost model:
| Cost Component | Typical Range | Often Forgotten? |
|---|---|---|
| Initial engineering | 2-6 engineer-months | No |
| Opportunity cost | 2-6 months of those engineers not building core features | Yes |
| Infrastructure | $500-5,000/month | Sometimes |
| Security/compliance | $10K-50K/year (audits, pen testing) | Yes |
| Ongoing maintenance | 20-30% of build cost annually | Yes |
| On-call/incident response | 5-10% of one engineer's time | Yes |
| Documentation and onboarding | 1-2 engineer-weeks | Yes |
| Future migration/upgrade | Unpredictable | Yes |
Example: In-house authentication.
- Build cost: 3 engineers x 2 months = $100K-150K in loaded salary
- Maintenance: $30K-50K/year (security patches, new auth methods, compliance)
- Opportunity cost: 6 engineer-months not spent on your core product
- Total 3-year cost: $250K-400K
Versus Auth0/Clerk:
- Year 1: $3K-30K (depends on user volume)
- Year 2: $5K-50K (scales with growth)
- Year 3: $10K-80K (continues scaling)
- Total 3-year cost: $18K-160K
For most companies, buying auth is the right call. Use the RICE framework to evaluate whether building a given capability creates enough user impact to justify the engineering cost.
Build Risks
- Scope creep. What starts as a "simple" internal tool grows into a full product. Engineers want to add features. Stakeholders request customizations. The project stretches from 2 months to 8.
- Key-person dependency. The engineer who built the system leaves. Nobody else understands it. Maintenance becomes expensive and risky.
- Falling behind. Vendors invest their entire company in improving the capability. Your in-house solution, maintained by one engineer part-time, falls behind on features, performance, and security.
- Distraction from core product. Every hour spent on infrastructure is an hour not spent on what customers actually pay you for.
Buy. Deep Dive
Buying means purchasing a vendor solution (SaaS, API, or SDK) that provides the capability. You integrate it into your product and rely on the vendor for maintenance, updates, and scaling.
When Buying Wins
Commodity infrastructure. Email delivery, authentication, payment processing, monitoring, analytics, error tracking, feature flags. These are solved problems. Dozens of vendors compete on price and quality. Building any of these in-house wastes engineering time that should go toward your product.
Speed to market. When launching fast matters more than long-term optimization, buying is almost always right. A startup racing to prove product-market fit should buy everything that isn't the core product. You can always replace a vendor later. You can't un-waste the 6 months you spent building a custom analytics pipeline.
Specialized expertise. Vendors who focus entirely on one problem (Stripe on payments, Twilio on communications, Datadog on monitoring) produce better solutions than your team can build part-time. Their product is maintained by hundreds of engineers. Your alternative is one engineer spending 20% of their time.
Compliance and certification. Vendors like Stripe and AWS handle PCI compliance, SOC2 audits, and regional data residency. Building equivalent compliance infrastructure in-house costs $100K-500K and takes months.
The True Cost of Buying
Vendor costs grow in ways that aren't obvious at signing:
| Cost Component | Typical Range | Often Forgotten? |
|---|---|---|
| Subscription/usage fee | $100-50,000/month | No |
| Integration engineering | 1-4 engineer-weeks | Sometimes |
| Ongoing integration maintenance | 2-5 days/quarter (API changes) | Yes |
| Vendor management | 1-2 hours/month (reviews, support) | Yes |
| Workarounds for missing features | Variable (custom code around vendor limits) | Yes |
| Migration cost (if switching) | 2-8 engineer-weeks | Yes |
| Data export/portability | Often limited or manual | Yes |
Vendor lock-in escalation. Year 1: the vendor costs $500/month and works great. Year 3: usage has grown, you're on a $5,000/month plan, the vendor raised prices 15%, and you've built 6 custom integrations that would take 3 months to replicate with another vendor. The switching cost now exceeds the build cost. This is by design. Vendors want lock-in.
Buy Risks
- Vendor outage. When Stripe goes down, your checkout goes down. When AWS us-east-1 has an incident, half the internet goes down. You inherit the vendor's reliability as your own.
- Price increases. Vendors raise prices after you're locked in. Heroku, Segment, and others have done significant price increases that forced customers to migrate at the worst possible time.
- Feature gaps. The vendor builds for their median customer. If your needs are unusual, you'll spend engineering time building workarounds that partially defeat the purpose of buying.
- Data access limitations. Vendors control your data. Export formats may be incomplete. Real-time access to raw data may require premium tiers. When you switch, getting your data out can be painful.
Partner. Deep Dive
Partnering goes beyond a vendor relationship. It involves a business relationship where both companies invest in the integration and share in the value created. Partnerships range from simple API integrations with revenue sharing to deep co-development and co-marketing agreements.
When Partnering Wins
Domain expertise you can't build. A fintech company partnering with a bank for regulatory infrastructure. A healthcare startup partnering with an EHR vendor for clinical data access. An e-commerce platform partnering with a logistics company for fulfillment. In each case, the partner has decades of domain expertise that you couldn't replicate in years.
Market access and distribution. Partnerships with companies that have your target customers can accelerate growth faster than direct sales. A project management tool partnering with Salesforce to appear in the AppExchange reaches millions of potential customers through an existing distribution channel.
Mutual value creation. The best partnerships create value that neither company could create alone. Stripe and Shopify's partnership benefits both: Shopify gets reliable payments, Stripe gets massive transaction volume. Neither would be better off building the other's capability in-house.
Risk and cost sharing. Entering a new market, developing a new technology, or serving a new customer segment is cheaper and less risky with a partner who shares the investment. Joint ventures for new products split both the cost and the upside.
Partnership Types
| Type | Description | Example | Risk Level |
|---|---|---|---|
| API integration | Your product connects to the partner's API | Zapier integrations | Low |
| Channel partnership | Partner sells/distributes your product | Salesforce AppExchange | Moderate |
| Technology partnership | Co-develop a shared capability | Apple Pay + bank integrations | Moderate |
| Strategic alliance | Deep business integration, shared go-to-market | Stripe + Shopify | High |
| White-label/OEM | Partner's technology, your brand | Banking-as-a-Service providers | High |
The True Cost of Partnering
| Cost Component | Typical Range | Often Forgotten? |
|---|---|---|
| Legal/contract negotiation | $10K-100K (1-3 months) | Sometimes |
| Technical integration | 2-8 engineer-weeks | No |
| Partnership management | 5-10 hours/month ongoing | Yes |
| Revenue sharing | 10-30% of partnership revenue | No |
| Co-marketing commitments | Variable (events, content, campaigns) | Sometimes |
| Integration maintenance | 1-3 days/quarter | Yes |
| Relationship repair (when things break) | Unpredictable, high-stress | Yes |
Partnership Risks
- Misaligned incentives. The partner's priorities change. What was a mutual win becomes a one-sided drain. This happens most often after the partner gets acquired or changes leadership.
- Dependency without control. You depend on the partner's API, support quality, and roadmap decisions, but you have no vote. When the partner deprecates an API endpoint, you scramble.
- Brand contamination. Your customers interact with the partner's product through your interface. If the partner's product is slow, buggy, or has poor UX, your customers blame you.
- Revenue sharing disputes. Attribution gets messy. Who brought the customer? Who expanded the account? Partnership revenue models create ongoing friction.
- Non-compete evolution. A partner who complemented you today may compete with you tomorrow. The closer the partnership, the more the partner learns about your customers and market.
Decision Matrix
Use this framework to evaluate any new capability:
Step 1: Is this a core differentiator?
If yes, build. If losing control of this capability would weaken your competitive position, it must be in-house.
If no, proceed to Step 2.
Step 2: Does a good vendor solution exist?
If yes, buy (unless one of these conditions applies):
- Vendor pricing at your expected scale exceeds 3-year build cost
- Vendor's data handling doesn't meet your compliance requirements
- The integration you need doesn't exist and the vendor won't build it
If no vendor fits, proceed to Step 3.
Step 3: Can a partner provide the capability?
If yes, evaluate the partnership against building:
- Partner when the partner has domain expertise you lack, the integration creates mutual value, and the relationship can be structured with clear terms.
- Build when no suitable partner exists, the partnership terms are unfavorable, or the capability will become a core differentiator in the future.
The 3-Year Test
For any build-vs-buy-vs-partner decision, project the total cost of ownership over three years. Include all the hidden costs listed above. The option with the lowest 3-year TCO that meets your requirements usually wins. But weight strategic factors too: control over a core differentiator is worth paying more for.
Real-World Decision Examples
These examples illustrate how the framework applies to common product decisions.
Payment Processing
Most companies: Buy (Stripe, Adyen). Payment processing is commodity infrastructure for 99% of companies. Stripe charges 2.9% + $0.30 per transaction. Building your own payment processing requires PCI-DSS compliance ($50K-200K/year), banking relationships, fraud detection, and a team of specialists. Only companies processing $100M+ in annual transactions should consider building.
Exception: Shopify built Shopify Payments. Payments became a core differentiator. By owning the payment experience, Shopify captures payment revenue (their largest revenue source), controls the merchant experience, and offers features like Shop Pay that competitors can't match.
Search Functionality
Small to mid products: Buy (Algolia, Elasticsearch Service). Search is technically complex and requires ongoing tuning. Algolia costs $1-5K/month for most products. Building equivalent search quality in-house requires 2-3 engineers for 3-6 months plus ongoing maintenance.
Large products with search-centric UX: Build. If search quality directly affects user retention and revenue (e-commerce, content platforms, marketplaces), owning the search stack lets you optimize for your specific use case. Pinterest, Airbnb, and Spotify all built custom search and recommendation systems because search is their product.
Compliance and Regulatory Features
Most companies: Partner. Compliance requires domain expertise that takes years to develop. Partner with compliance-specialized vendors (Vanta for SOC2, Drata for security compliance, specialized legal tech for industry regulations). The partner handles evolving regulations while you focus on your product.
Regulated industries: Build the compliance layer. If regulatory compliance is part of your value proposition (healthcare, fintech, govtech), build the compliance infrastructure in-house. Your customers choose you because you understand their regulatory requirements. Outsourcing that understanding to a vendor weakens your differentiation.
Analytics and Reporting
Early stage: Buy (Amplitude, Mixpanel, PostHog). Product analytics is a solved problem with dozens of excellent tools. Building a custom analytics pipeline before product-market fit is a waste of engineering resources.
At scale: Hybrid (buy the platform, build custom pipelines). Companies at scale often supplement a vendor analytics platform with custom data pipelines for specific use cases: revenue analytics, ML feature pipelines, real-time dashboards. The vendor handles standard product analytics. Custom pipelines handle business-specific needs.
For a more detailed two-option analysis of the build-vs-buy question, see the dedicated build vs buy comparison.
Common Mistakes
Building commodity infrastructure. The most common mistake. Engineering teams want to build everything because it's more interesting than integrating a vendor. A custom-built email delivery system is not a competitive advantage for 99% of companies. Buy it and move on.
Buying core differentiators. The opposite mistake. Using an off-the-shelf recommendation engine when recommendations are your core product gives away your competitive moat. If the algorithm is what customers pay for, own it.
Treating partnerships as vendor relationships. Partnerships require investment from both sides. Companies that treat partners as vendors (minimal communication, transactional relationship, no shared planning) get vendor-level outcomes. The partnership's value comes from the relationship, not the contract.
Never revisiting the decision. A "buy" decision made at 10 customers may not be right at 10,000 customers. A "build" decision made when your team had 50 engineers may not be right when you have 15. Review your major build/buy/partner decisions annually.
Ignoring opportunity cost. The most invisible cost. Every engineer-month spent building internal tools is an engineer-month not spent on the product customers pay for. Product leaders who track opportunity cost make better build-vs-buy decisions because they see what they're giving up.
For a structured approach to prioritizing engineering investments, the RICE framework quantifies impact versus effort. The Product Strategy Handbook covers portfolio allocation decisions at the strategic level.
Bottom Line
Build your core differentiators. Buy commodity infrastructure. Partner for domain expertise and market access. Apply the 3-year TCO test to every decision, include opportunity cost, and revisit major decisions annually. The most common mistake is building too much (engineering teams default to building because it's more interesting) and the second most common is never revisiting the decision after conditions change.