Handbook
/
Product & Engineering
When to Build vs Buy vs Integrate
Every engineering decision involves choosing between building custom, buying a solution, or integrating existing tools. Here's how to decide.
Engineers love building. It’s what they’re trained for, what they enjoy, and often what they’re measured on. But building everything from scratch is a startup trap. It drains resources, delays shipping, and creates maintenance burden.
The strategic question: When should you build, when should you buy, and when should you just integrate existing tools?
The Build Bias
Startups over-build for several reasons:
NIH Syndrome (Not Invented Here). Engineers distrust external solutions. “We can build something better suited to our needs.”
Control. Custom solutions feel safer. You control the roadmap, the uptime, the data.
Resume-driven development. Building interesting things is more fun than gluing together services. Engineers optimize for learning, not business value.
Underestimating maintenance. The initial build might be two weeks, but maintenance is forever. This isn’t factored in.
Overestimating uniqueness. “Our requirements are unique” is usually false. Most features have been built a thousand times.
The Decision Framework
1. Is This Core to Your Value Proposition?
If the feature is what makes your product special—what customers pay for, what differentiates you—build it. You need control, customization, and competitive advantage.
If it’s commodity functionality that every app needs but isn’t your differentiator—buy or integrate.
Examples:
•
If you’re a payment company, build payment processing. Everyone else: use Stripe.
•
If you’re a search engine, build search. Everyone else: use Algolia or Elasticsearch.
•
If you’re a design tool, build your canvas. Everyone else: use a library.
2. Does a Good-Enough Solution Exist?
Search for existing solutions. SaaS, open source, APIs—the ecosystem is vast.
Questions to ask:
•
Does this solve at least 80% of our requirements?
•
What’s the cost? Is it sustainable for our budget?
•
Who else uses it? Are they similar to us?
•
What’s the vendor’s track record and stability?
•
Can we migrate away if needed?
If a good-enough solution exists at a reasonable price, the bar for building is high.
3. What’s the True Cost of Building?
Calculate honestly:
Initial development: Engineer time × hourly cost × weeks
Ongoing maintenance: Bug fixes, updates, security patches. Estimate 20-30% of initial cost per year.
Opportunity cost: What else could those engineers build?
Learning curve: Time to understand the domain
Infrastructure: Hosting, monitoring, on-call
Often, the SaaS subscription that looks expensive is actually cheaper than building.
Example calculation:
•
SaaS cost: $500/month = $6,000/year
•
Build cost: 2 engineers × $75/hour × 3 weeks = $18,000 initial
•
Maintenance: $5,000/year
•
First year total: $23,000 vs $6,000. Three years: $33,000 vs $18,000.
The math often favors buying.
4. How Critical Is This to Operations?
High-criticality functionality (authentication, payments, infrastructure) requires high reliability. Can you match the reliability of vendors who specialize in this?
Stripe has teams dedicated to payment reliability. Can you? Probably not. AWS has SREs keeping databases running. Can you? Probably not.
For critical infrastructure, specialized vendors are usually safer than custom builds.
5. What Are the Lock-in Risks?
Consider how much you’ll depend on this solution:
•
Can you export your data?
•
Are there standard APIs/formats that allow switching?
•
What happens if the vendor raises prices or goes out of business?
Some lock-in is acceptable if the value is high. But prefer solutions with clear exit paths.
Categories of Decisions
Almost Always Buy/Integrate
These are solved problems. Building is almost never justified:
•
Authentication: Auth0, Clerk, Firebase Auth, Supabase Auth
•
Payments: Stripe, Paddle, Braintree
•
Email sending: SendGrid, Postmark, Resend
•
Email receiving: Mailgun, SendGrid inbound
•
SMS: Twilio, Vonage
•
Push notifications: OneSignal, Firebase
•
Search: Algolia, Typesense, Meilisearch
•
Error tracking: Sentry, Bugsnag
•
Analytics: Amplitude, Mixpanel, PostHog
•
Logging/monitoring: Datadog, New Relic, Grafana Cloud
•
Feature flags: LaunchDarkly, PostHog, Statsig
•
File storage: AWS S3, Cloudflare R2
•
Video/audio: Mux, Cloudinary
•
Background jobs: Inngest, Trigger.dev
Usually Build
These often require customization that vendors can’t provide:
•
Core product features
•
Business logic specific to your domain
•
User-facing experiences central to your value prop
•
Integrations between your core systems
•
Data pipelines specific to your analytics needs
Case-by-Case
These depend on your specific needs:
•
CMS: Sanity, Contentful, or custom?
•
Notifications system: Knock, Novu, or custom?
•
Admin panels: Retool, custom?
•
Customer support: Intercom, custom?
•
Billing/subscriptions: Stripe Billing, custom?
Evaluate based on requirements, budget, and customization needs.
Integration Patterns
When using external services, how you integrate matters:
Wrap External Services
Create an abstraction layer around external services:
// Good: Wrapped payment service
interface PaymentService {
charge(amount: number, customerId: string): Promise<Charge>;
}
class StripePaymentService implements PaymentService {
// Stripe implementation
}
This allows switching vendors without changing application code.
Design for Fallbacks
What if the external service goes down?
•
Cache data where possible
•
Implement graceful degradation
•
Have alerts for service disruptions
•
Consider backup providers for critical paths
Monitor External Dependencies
Track:
•
Response times from external services
•
Error rates
•
Cost per request
•
Usage trends
Visibility prevents surprises.
Making the Case
Sometimes you need to advocate for buying over building (or vice versa):
To advocate for buying:
•
Calculate total cost of ownership for build vs. buy
•
List what engineers could build instead
•
Show risk comparison (vendor reliability vs. your team’s)
•
Find case studies of similar companies
To advocate for building:
•
Demonstrate unique requirements vendors can’t meet
•
Show strategic value of owning this capability
•
Calculate lock-in risks and exit costs
•
Explain competitive advantage of customization
Red Flags
Build bias: “We can build something better” without evidence that existing solutions are inadequate.
Buy bias: “Let’s just use a service” for core functionality that differentiates your product.
Ignoring hidden costs: Not accounting for maintenance, learning curves, integration time.
Assuming forever: Both build and buy decisions should be revisited as circumstances change.
Key Takeaways
•
Build what’s core to your value proposition; buy/integrate everything else
•
Search for existing solutions before building—the ecosystem is vast
•
Calculate true cost: initial development + maintenance + opportunity cost
•
Specialized vendors often provide better reliability than your team can
•
Wrap external services for flexibility; design for fallbacks
•
Revisit decisions as your needs and scale change
AIMake has access to all of this
Our AI has access to the entire Startup Handbook. Ask it anything about building your startup.
Get started →
← Previous
API-First Thinking: Why It Matters Early
Next →
Choosing Your Tech Stack as a Non-Technical Founder