In today's guest post I'm breaking down everything I've learned about build vs. buy decisions across 15+ years of product leadership:
- Why Build vs. Buy matters more than ever
- The real framework for making the decision
- How to win over finance, procurement, and other stakeholders
- Red flags to when you should buy
- When you absolutely must build
- Most common mistakes to avoid
1. Why Build vs. Buy matters more than ever
The stakes for build vs. buy decisions have never been higher.
Here's why:
The rise of specialized solutions
Ten years ago, if you wanted document automation, you had to build it. Today? Companies like Anvil offer sophisticated solutions that can be implemented in days, not months.
Engineering talent is expensive (and scarce)
The average fully-loaded cost of a senior engineer is now $200k+ annually. Every hour they spend building non-core functionality is an hour not spent on your competitive advantage.
Speed to market is everything
In today's market, being six months late can mean losing your entire market opportunity. The right buy decision can cut your time-to-market by 70% or more.
Technical debt is the silent killer
Every piece of custom code you write is code you'll have to maintain—forever. In an era of rapid technological change, that maintenance burden can become crippling.
2. Framework for making the build vs. buy decision
Forget the oversimplified flowcharts you've seen. Here's how successful product leaders actually make build vs. buy decisions:
Step 1: Define your core
Start by asking: "What makes our product uniquely valuable to customers?"
This isn't just theoretical—it's about identifying what drives revenue and customer loyalty. Everything else is a candidate for buying.
Example: At Apollo.io, our core was our data enrichment and scoring algorithms. Everything else—from authentication to email delivery—we bought.
Step 2: Calculate the True Cost
The biggest mistake teams make is underestimating the true cost of building. Here's what to include:
- Initial development time
- Ongoing maintenance (varies, but usually 20% of initial development annually)
- Security updates and compliance
- Documentation and training
- Opportunity cost of engineers not working on core features
- Risk of delays and overruns
Step 3: Assess the Market
Before deciding to build, thoroughly evaluate existing solutions:
- How mature are the vendors?
- What's their pricing model?
- How well do they integrate with your stack?
- What's their roadmap and innovation pace?
Tactical tip: Don't just look at feature lists. Talk to other companies using these solutions. Ask about implementation time, support quality, and hidden gotchas.
3. How to win over finance, procurement, and other stakeholders
The technical decision is often the easy part. The real challenge? Getting stakeholder buy-in.
Working with Finance
Finance sees the world in numbers. Give them what they need:
- Total Cost of Ownership (TCO) analysis
- ROI calculations including time-to-market benefits
- Risk assessment of build vs. buy options
- Competitive analysis of vendor pricing
Tactical tip: Always include the opportunity cost in your TCO analysis. If building takes four engineers six months, that's two years of engineering time not spent on core features.
Navigating procurement
Procurement teams have specific concerns. Address them head-on:
- Security and compliance documentation
- Vendor financial stability
- Service Level Agreements (SLAs)
- Contract terms and negotiation points
Getting engineering buy-in
Engineers often prefer to build. Here's how to align them:
- Focus on the interesting problems they'll get to solve instead
- Show how buying accelerates the roadmap
- Demonstrate the vendor's technical sophistication
- Include them in vendor evaluation
4. Red flags that you should buy (not build)
Here are critical red flags that should push you toward buying:
1. Multiple competing vendors exist
When you see a crowded marketplace of solutions, pay attention. This usually indicates:
- The problem space is well-understood
- Major edge cases have been discovered and solved
- Market competition is driving innovation and reliability
- Pricing has stabilized to reflect true value
Real-world example: The customer support ticketing system market. Companies like Zendesk, Freshdesk, and Intercom have collectively spent decades refining their solutions. Building your own would mean retracing their entire learning curve.
Strategic implication: Your time-to-market with a custom solution will always lag behind established vendors who have years of accumulated knowledge and customer feedback.
2. Feature is common across industries
When functionality is standardized across different sectors, it's a strong signal to buy. Look for:
- Well-established best practices
- Standard user expectations
- Common integration patterns
- Predictable feature sets
Product leader tip: Ask yourself, "Will our implementation of this feature give us any competitive advantage?" If not, you're probably better off buying.
3. High security/compliance requirements
This is often the most expensive aspect of building in-house. Modern compliance requirements include:
- SOC 2 Type II certification
- GDPR compliance
- HIPAA requirements
- PCI DSS standards
- ISO 27001 certification
Hidden costs include:
- Regular security audits
- Compliance documentation
- Ongoing monitoring
- Incident response planning
- Security team hiring
Real-world insight: A single compliance certification can cost $100,000+ and take 6-12 months. Vendors amortize this cost across their entire customer base.
4. Not directly tied to revenue
Your engineering resources should focus on features that directly drive revenue or competitive advantage. Be especially wary of building when:
- The feature is infrastructural (authentication, logging, monitoring)
- It's a commodity service (email delivery, payment processing)
- Users expect it but don't pay extra for it
- It's a cost center rather than a profit center
Strategic consideration: Every engineering hour spent on non-core features is an hour not spent on your differentiators.
5. Requires ongoing maintenance
The true cost of building often reveals itself in maintenance. Watch for features that need:
- Regular security updates
- API version management
- Performance optimization
- Bug fixes and patches
- Documentation updates
- Training materials
- Customer support resources
Product leader insight: The rule of thumb is that maintenance costs 15-20% of the initial development cost annually. For a feature that took 6 months to build, that's 1-2 months of engineering time every year.
6. Complex edge cases
When you start discovering numerous edge cases, it's often a sign you should buy. Watch for:
- International requirements (time zones, currencies, languages)
- Platform-specific behaviors
- Legacy system compatibility
- Regulatory variations by region
- Complex user scenarios
Real-world example: A "simple" calendar scheduling feature becomes complex when you consider:
- Daylight savings time
- International date formats
- Recurring meeting patterns
- Calendar provider integrations
- Timezone conversions
- Availability conflicts
Product leader tip: When mapping requirements, count the number of "edge cases" you discover. If they exceed 20% of your core use cases, seriously consider buying.
Making the call
The presence of any three of these red flags should trigger a serious evaluation of buying over building. When four or more are present, the decision to buy should be your default position unless you have compelling evidence otherwise.
Remember: Your job as a product leader isn't to build everything—it's to deliver value to customers in the most efficient way possible. Sometimes that means knowing when to let someone else solve the problem for you.
5. When you absolutely must build
While buying is often the safer choice, there are compelling scenarios where building is not just preferred—it's essential for business success. Understanding these scenarios is crucial for making confident build decisions.
1. Core intellectual property
When the functionality represents your core competitive advantage, building is non-negotiable. This includes:
Key differentiators:
- Proprietary algorithms
- Unique data processing methods
- Novel user experiences
- Breakthrough technology approaches
Strategic value:
- Creates barriers to entry
- Delivers unique customer value
- Drives pricing power
- Enables market leadership
Real-world example: Netflix's recommendation engine. While they could have licensed existing recommendation technology, building their own allowed them to:
- Incorporate unique viewing behavior data
- Optimize for streaming-specific patterns
- Create defensible competitive advantages
- Control their product destiny
Product leader tip: Ask yourself, "Would sharing this capability with competitors fundamentally damage our market position?" If yes, build it.
2. Unique market requirements
Building becomes necessary when your needs significantly diverge from standard market solutions. Look for:
Market Gaps:
- Unaddressed user needs
- Industry-specific workflows
- Novel technical requirements
- Emerging market opportunities
Validation Criteria:
- Existing solutions miss critical features
- Customization won't bridge the gap
- Market size justifies investment
- Time-to-market advantage exists
Real-world insight: Before building, ensure your "unique" requirements are truly unique and not just preferences. I've seen teams build custom solutions only to realize they've created an expensive, harder-to-maintain version of existing products.
3. Strategic control
Sometimes, maintaining control over critical functionality outweighs the benefits of buying. Consider building when:
Business Critical Factors:
- Core business processes depend on it
- Rapid iteration is essential
- Performance requirements are extreme
- Integration needs are complex
Risk Assessment:
- Vendor lock-in threatens operations
- Market consolidation is likely
- Regulatory changes demand agility
- Competitive dynamics require flexibility
Product leader insight: The decision to build for strategic control should be based on concrete risks, not theoretical concerns. Document specific scenarios where vendor dependence could harm your business.
The product leader's perspective
Remember: The decision to build should be driven by strategy, not preference. Ask yourself:
- Does this capability fundamentally differentiate our product?
- Can we maintain and evolve it better than vendors?
- Does building create sustainable competitive advantage?
- Is the long-term investment justified by business value?
Only when you can confidently answer "yes" to these questions should you proceed with building.
Final Thought: Building is a long-term commitment. Make sure your organization is prepared not just for the initial development, but for years of evolution and maintenance. The decision to build should be made with the same rigor as a major strategic investment—because that's exactly what it is.
6. Common mistakes to avoid
Mistake 1: The "not invented here" syndrome
Engineers love to build. It's in their DNA. But just because you can build something doesn't mean you should.
Real Example: At Epic Online Services, we initially built our own document processing system. Six months and thousands of engineering hours later, we realized we'd built a worse version of what we could have bought off the shelf.
Mistake 2: Underestimating maintenance
That "simple" internal tool you built? It now needs security updates, bug fixes, and feature requests. The maintenance burden never goes away.
Mistake 3: False economy
Thinking you're saving money by building, when you're actually:
- Tying up expensive engineering resources
- Delaying time to market
- Creating technical debt
- Missing out on vendor innovations
Mistake 4: Ignoring the ecosystem
Modern SaaS solutions come with entire ecosystems—integrations, communities, best practices. Building means you lose access to this collective wisdom.
Mistake 5: Poor vendor selection
If you decide to buy, do your homework:
- Check references thoroughly
- Test integration capabilities
- Evaluate support quality
- Understand the pricing model
- Assess company stability
Final thoughts
The build vs. buy decision isn't just about technology—it's about strategy. In today's market, the winners are those who know where to focus their engineering resources and where to leverage existing solutions.
For functions like document automation, the decision is increasingly clear. Solutions like Anvil offer sophisticated capabilities that would take months or years to build and maintain internally. The real question isn't whether to build or buy—it's how quickly you can integrate these solutions and move on to what really matters: building your core product.
Remember: Your engineers are your most valuable resource. Every hour they spend building commodity features is an hour not spent on your competitive advantage.
Make the smart choice. Buy what you can, build what you must.
Your engineers (and your CEO) will thank you.