When to Build vs Buy: Evaluating Third-Party SaaS as an Architect
February 18, 2026141 min read16 views
When to Build vs Buy: Evaluating Third-Party SaaS as an Architect
Introduction
"Should we build this ourselves or buy a solution?"
This question lands on architects' desks weekly. Get it wrong, and you've either wasted months of engineering time reinventing the wheel or locked your organization into an expensive, inflexible dependency. Get it right, and you've accelerated your roadmap while preserving optionality.
This guide provides a systematic framework for making build vs buy decisions, drawn from hard-won lessons across organizations of all sizes.
The False Dichotomy
First, let's dispel a myth: build vs buy isn't binary.
The Real Spectrum:
┌─────────────────────────────────────────────────────────────────┐
│ │
│ FULL OPEN HOSTED SaaS SaaS FULL │
│ BUILD SOURCE OPEN with with BUY │
│ SELF- SOURCE CONFIG CUSTOM │
│ HOSTED INTEGRATION │
│ │
│ ◄─────────────────────────────────────────────────────────► │
│ More Control Less Maintenance │
│ More Maintenance Less Control │
│ │
└─────────────────────────────────────────────────────────────────┘
The Six Options:
| Option | Example | Control | Maintenance |
|---|---|---|---|
| Full Build | Custom auth system | Complete | Very High |
| Open Source Self-Hosted | Keycloak on your infra | High | High |
| Hosted Open Source | Supabase, Neon | Medium-High | Medium |
| SaaS with Config | Auth0, Stripe | Medium | Low |
| SaaS with Custom Integration | Salesforce + custom middleware | Low-Medium | Medium |
| Full Buy (Turnkey) | Shopify for e-commerce | Low | Very Low |
Your job isn't choosing "build" or "buy"—it's finding the right point on this spectrum.
The Decision Framework
Phase 1: Strategic Alignment
Before evaluating any solution, answer these questions:
┌─────────────────────────────────────────────────────────────┐
│ STRATEGIC ALIGNMENT CHECKLIST │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. CORE vs CONTEXT │
│ □ Is this a competitive differentiator? │
│ □ Does this directly impact customer value? │
│ □ Would competitors gain advantage if they had this? │
│ │
│ 2. STRATEGIC DIRECTION │
│ □ Does this align with our 3-year technical vision? │
│ □ Does this fit our build vs buy philosophy? │
│ □ Is this domain we want to develop expertise in? │
│ │
│ 3. ORGANIZATIONAL CAPABILITY │
│ □ Do we have expertise to build this well? │
│ □ Can we maintain this long-term? │
│ □ Is building this a good use of our talent? │
│ │
└─────────────────────────────────────────────────────────────┘
The Core vs Context Framework:
Geoffrey Moore's framework remains the most useful lens:
HIGH STRATEGIC IMPORTANCE
│
│
┌──────────────────┼──────────────────┐
│ │ │
│ MISSION │ CORE │
│ CRITICAL │ DIFFERENTIATOR│
│ │ │
│ "Must work │ "Build this │
│ perfectly" │ ourselves" │
│ │ │
│ Buy reliable │ Build & invest │
│ enterprise │ heavily │
│ solutions │ │
LOW │ │ │ HIGH
UNIQUENESS├──────────────────┼──────────────────┤ UNIQUENESS
│ │ │
│ COMMODITY │ CONTEXT │
│ │ ADVANTAGE │
│ "Just needs │ │
│ to work" │ "Nice to have │
│ │ our way" │
│ Buy cheapest │ │
│ that works │ Buy & customize │
│ │ │
└──────────────────┼──────────────────┘
│
LOW STRATEGIC IMPORTANCE
Examples by Quadrant:
┌─────────────────┬─────────────────────────────────────────────┐
│ CORE │ Recommendation engine (Netflix) │
│ DIFFERENTIATOR │ Search algorithm (Google) │
│ │ Design tools (Figma) │
│ │ → BUILD: This IS your product │
├─────────────────┼─────────────────────────────────────────────┤
│ MISSION │ Payment processing (for most companies) │
│ CRITICAL │ Authentication (for most companies) │
│ │ Database infrastructure │
│ │ → BUY: Reliability > customization │
├─────────────────┼─────────────────────────────────────────────┤
│ CONTEXT │ Analytics dashboards │
│ ADVANTAGE │ Customer support tools │
│ │ Internal admin panels │
│ │ → BUY + CUSTOMIZE: Good enough + integrated │
├─────────────────┼─────────────────────────────────────────────┤
│ COMMODITY │ Email sending │
│ │ File storage │
│ │ Logging │
│ │ → BUY CHEAPEST: It just needs to work │
└─────────────────┴─────────────────────────────────────────────┘
Phase 2: Requirements Analysis
Document requirements with brutal honesty:
interface RequirementsAnalysis {
// Functional Requirements
functional: {
mustHave: Requirement[]; // Non-negotiable
shouldHave: Requirement[]; // Important
niceToHave: Requirement[]; // Can live without
};
// Non-Functional Requirements
nonFunctional: {
performance: {
latencyP99: number; // milliseconds
throughput: number; // requests/second
availability: number; // percentage (99.9%, 99.99%)
};
scale: {
currentLoad: number;
projectedLoad: number; // 2-year projection
peakMultiplier: number; // Black Friday factor
};
security: {
complianceFrameworks: string[]; // SOC2, HIPAA, PCI
dataResidency: string[]; // regions
encryptionRequirements: string[];
};
integration: {
existingSystems: string[];
dataFlowRequirements: DataFlow[];
latencyBudget: number;
};
};
// Constraints
constraints: {
budget: {
initial: number;
annual: number;
hardCeiling: number;
};
timeline: {
mvpDeadline: Date;
fullDeadline: Date;
flexibility: 'none' | 'some' | 'flexible';
};
team: {
availableEngineers: number;
relevantExpertise: string[];
canHire: boolean;
};
};
}
The Requirements Honesty Test:
┌─────────────────────────────────────────────────────────────┐
│ REQUIREMENTS HONESTY CHECKLIST │
├─────────────────────────────────────────────────────────────┤
│ │
│ For each "must have" requirement, ask: │
│ │
│ □ Has a customer explicitly asked for this? │
│ □ Will we lose deals without this? │
│ □ Is there a regulatory/compliance mandate? │
│ □ Have we validated this isn't just "nice to have"? │
│ │
│ Red flags that requirements are inflated: │
│ │
│ ⚠ "We might need this someday" │
│ ⚠ "Our competitor has this" │
│ ⚠ "It would be cool if..." │
│ ⚠ "Engineering would prefer..." │
│ ⚠ No customer has ever mentioned this │
│ │
└─────────────────────────────────────────────────────────────┘
Total Cost of Ownership Analysis
The most common mistake in build vs buy is comparing subscription costs to development costs. Real TCO is far more complex.
The Build Cost Iceberg
▲
/│\ What people see:
/ │ \ "It's just 3 weeks of
/ │ \ engineering work"
/ │ \
/────┼────\
/ │ \ ════════════════════
/ │ \ ACTUAL COSTS BELOW
/ │ \
/ │ \
/ Initial │ Dev \
/ Design │ Time \
/───────────┼───────────\
/ Code │ Testing \
/ Reviews │ & QA \
/──────────────┼─────────────\
/ Security │ Performance \
/ Review │ Tuning \
/─────────────────┼────────────────\
/ Documentation │ Deployment \
/ │ & DevOps \
────────────────────┼──────────────────
On-call │ Bug fixes
Rotation │ & Patches
────────────────────┼──────────────────
Knowledge │ Training
Transfer │ New Hires
────────────────────┼──────────────────
Compliance │ Audit
Updates │ Support
────────────────────┼──────────────────
Feature │ Tech Debt
Requests │ Paydown
────────────────────┼──────────────────
Opportunity │ Delayed
Cost │ Roadmap
────────────────────┴──────────────────
TCO Calculation Model
interface TCOModel {
buildCosts: {
// Initial Development
initial: {
engineeringHours: number;
hourlyRate: number; // Fully loaded (salary + benefits + overhead)
designReviewHours: number;
securityReviewHours: number;
documentationHours: number;
testingHours: number;
deploymentSetup: number;
};
// Ongoing Maintenance (Annual)
maintenance: {
bugFixesPercent: number; // Typically 15-20% of initial dev
securityPatches: number; // Hours per year
performanceTuning: number;
dependencyUpdates: number;
complianceUpdates: number;
featureRequests: number; // Internal enhancement requests
};
// Operational Costs (Annual)
operations: {
infrastructure: number; // Cloud costs
monitoring: number; // Tools and time
onCallHours: number; // Incident response
incidentCost: number; // Average cost per incident
expectedIncidents: number; // Per year
};
// Hidden Costs
hidden: {
knowledgeTransfer: number; // When people leave
trainingNewHires: number;
technicalDebtInterest: number;
opportunityCost: number; // What else could team build?
};
};
buyCosts: {
// Subscription/License
subscription: {
basePrice: number;
perUserPrice: number;
perUsagePrice: number;
expectedUsers: number;
expectedUsage: number;
priceIncreasePercent: number; // Annual escalation
};
// Integration Costs
integration: {
initialIntegration: number; // Hours
customization: number;
dataTransformation: number;
testing: number;
};
// Operational Costs (Annual)
operations: {
adminTime: number; // Hours managing the tool
supportEscalations: number;
workaroundDevelopment: number; // When it doesn't quite fit
trainingTime: number;
};
// Risk Costs
risks: {
vendorLockInCost: number; // Migration cost if vendor fails
dataExtractionDifficulty: number;
contractNegotiationTime: number;
securityAuditCost: number;
};
};
}
Three-Year TCO Comparison Template
┌─────────────────────────────────────────────────────────────────┐
│ 3-YEAR TCO COMPARISON: [CAPABILITY] │
├─────────────────────────────────────────────────────────────────┤
│ │
│ BUILD OPTION YEAR 1 YEAR 2 YEAR 3 │
│ ───────────────────────────────────────────────────────────── │
│ Initial Development $XXX,XXX - - │
│ Infrastructure $XX,XXX $XX,XXX $XX,XXX│
│ Maintenance (20% of initial) $XX,XXX $XX,XXX $XX,XXX│
│ On-call & Incidents $XX,XXX $XX,XXX $XX,XXX│
│ Feature Enhancements $XX,XXX $XX,XXX $XX,XXX│
│ Security & Compliance $XX,XXX $XX,XXX $XX,XXX│
│ ───────────────────────────────────────────────────────────── │
│ SUBTOTAL $XXX,XXX $XXX,XXX $XXX,XXX│
│ Opportunity Cost (2 engineers) $XXX,XXX $XXX,XXX $XXX,XXX│
│ ───────────────────────────────────────────────────────────── │
│ BUILD TOTAL $XXX,XXX $XXX,XXX $XXX,XXX│
│ │
│ BUY OPTION YEAR 1 YEAR 2 YEAR 3 │
│ ───────────────────────────────────────────────────────────── │
│ License/Subscription $XX,XXX $XX,XXX $XX,XXX│
│ Integration Development $XX,XXX $X,XXX $X,XXX │
│ Admin & Operations $X,XXX $X,XXX $X,XXX │
│ Training $X,XXX $X,XXX $X,XXX │
│ Vendor Management $X,XXX $X,XXX $X,XXX │
│ ───────────────────────────────────────────────────────────── │
│ BUY TOTAL $XX,XXX $XX,XXX $XX,XXX│
│ │
│ ═════════════════════════════════════════════════════════════ │
│ 3-YEAR DIFFERENCE BUILD: $X,XXX,XXX │
│ BUY: $XXX,XXX │
│ DELTA: $XXX,XXX │
└─────────────────────────────────────────────────────────────────┘
The Fully-Loaded Engineer Cost
Many calculations underestimate true engineering cost:
Base Salary (Senior Engineer) $180,000
────────────────────────────────────────────────
Benefits (25%) + $45,000
Payroll Taxes + $14,000
Equipment & Software + $5,000
Office/Remote Setup + $3,000
Training & Conferences + $5,000
Management Overhead (10%) + $18,000
HR & Admin Overhead (5%) + $9,000
Recruiting Cost (amortized) + $8,000
────────────────────────────────────────────────
FULLY LOADED ANNUAL $287,000
────────────────────────────────────────────────
Productive Hours (accounting for 1,600
meetings, PTO, admin, context-switching)
────────────────────────────────────────────────
EFFECTIVE HOURLY RATE ~$180/hour
Reality Check:
- That "3-week project" at 2 engineers = 240 hours × $180 = $43,200 initial
- Plus 20% annual maintenance = $8,640/year
- Plus opportunity cost of what they could have built instead
Vendor Evaluation Framework
Technical Due Diligence
┌─────────────────────────────────────────────────────────────┐
│ TECHNICAL EVALUATION MATRIX │
├─────────────────────────────────────────────────────────────┤
│ │
│ CATEGORY WEIGHT VENDOR A VENDOR B BUILD │
│ ───────────────────────────────────────────────────────── │
│ │
│ FUNCTIONALITY (30%) │
│ ├─ Core features 10% 9/10 7/10 10/10 │
│ ├─ Feature completeness 8% 8/10 9/10 6/10 │
│ ├─ Customization 7% 6/10 8/10 10/10 │
│ └─ Roadmap alignment 5% 7/10 8/10 10/10 │
│ │
│ INTEGRATION (25%) │
│ ├─ API quality 10% 9/10 7/10 10/10 │
│ ├─ SDK/Libraries 5% 8/10 6/10 10/10 │
│ ├─ Webhooks/Events 5% 9/10 8/10 10/10 │
│ └─ Data portability 5% 6/10 4/10 10/10 │
│ │
│ RELIABILITY (20%) │
│ ├─ Uptime SLA 8% 9/10 9/10 7/10 │
│ ├─ Performance 7% 8/10 7/10 8/10 │
│ └─ Disaster recovery 5% 9/10 8/10 6/10 │
│ │
│ SECURITY (15%) │
│ ├─ Compliance certs 5% 9/10 8/10 5/10 │
│ ├─ Security practices 5% 8/10 7/10 7/10 │
│ └─ Data handling 5% 8/10 7/10 9/10 │
│ │
│ SUPPORT (10%) │
│ ├─ Documentation 4% 8/10 6/10 4/10 │
│ ├─ Support quality 3% 7/10 8/10 10/10 │
│ └─ Community 3% 9/10 5/10 3/10 │
│ │
│ ───────────────────────────────────────────────────────── │
│ WEIGHTED TOTAL 100% 8.1 7.2 7.8 │
│ │
└─────────────────────────────────────────────────────────────┘
API Quality Assessment
interface APIQualityChecklist {
design: {
restful: boolean; // Follows REST conventions
consistent: boolean; // Consistent naming/patterns
versioned: boolean; // API versioning strategy
documented: boolean; // OpenAPI/Swagger spec
pagination: boolean; // Handles large datasets
filtering: boolean; // Query capabilities
};
reliability: {
rateLimits: {
documented: boolean;
reasonable: boolean; // Fits your use case
gracefulDegradation: boolean; // 429 handling
};
errorHandling: {
consistentFormat: boolean;
meaningfulMessages: boolean;
errorCodes: boolean;
retryGuidance: boolean;
};
idempotency: boolean; // Safe retries
};
performance: {
latencyP50: number;
latencyP99: number;
throughputLimit: number;
bulkOperations: boolean;
asyncOperations: boolean; // For long-running tasks
};
security: {
authMethods: string[]; // OAuth, API keys, etc.
scopeGranularity: boolean; // Fine-grained permissions
auditLogging: boolean;
ipAllowlisting: boolean;
mTLS: boolean;
};
developer_experience: {
sandbox: boolean; // Test environment
sdks: string[]; // Official SDKs
webhooks: boolean;
websockets: boolean; // Real-time updates
graphql: boolean; // If applicable
};
}
Integration Complexity Assessment
┌─────────────────────────────────────────────────────────────┐
│ INTEGRATION COMPLEXITY MATRIX │
├─────────────────────────────────────────────────────────────┤
│ │
│ COMPLEXITY LEVEL CHARACTERISTICS TIME FACTOR │
│ ───────────────────────────────────────────────────────── │
│ │
│ TRIVIAL - Standard REST API 1x │
│ - Good SDK available │
│ - Simple auth (API key) │
│ - No data transformation │
│ Example: Stripe payments │
│ │
│ SIMPLE - Some data mapping needed 2x │
│ - OAuth integration │
│ - Webhook handling │
│ - Basic error handling │
│ Example: SendGrid email │
│ │
│ MODERATE - Complex data models 4x │
│ - Multiple API endpoints │
│ - State synchronization │
│ - Custom middleware needed │
│ Example: Salesforce CRM │
│ │
│ COMPLEX - Bidirectional sync 8x │
│ - Real-time requirements │
│ - Complex auth flows │
│ - Significant transformation │
│ Example: ERP integration │
│ │
│ NIGHTMARE - Undocumented APIs 16x+ │
│ - Legacy protocols │
│ - Unreliable vendor │
│ - No sandbox environment │
│ Example: Legacy banking APIs │
│ │
└─────────────────────────────────────────────────────────────┘
Vendor Risk Assessment
Business Viability Analysis
┌─────────────────────────────────────────────────────────────┐
│ VENDOR VIABILITY SCORECARD │
├─────────────────────────────────────────────────────────────┤
│ │
│ FINANCIAL HEALTH Score: /10 │
│ ───────────────────────────────────────────────────────── │
│ □ Funding stage/profitability │
│ - Bootstrapped & profitable: +3 │
│ - Series C+: +2 │
│ - Series A/B: +1 │
│ - Pre-seed/Seed: 0 │
│ □ Revenue growth (if public/available) │
│ □ Burn rate vs runway (if known) │
│ □ Customer concentration risk │
│ │
│ MARKET POSITION Score: /10 │
│ ───────────────────────────────────────────────────────── │
│ □ Market share / competitive position │
│ □ Brand recognition │
│ □ Customer references in your industry │
│ □ Analyst coverage (Gartner, Forrester) │
│ │
│ OPERATIONAL MATURITY Score: /10 │
│ ───────────────────────────────────────────────────────── │
│ □ Time in market (years) │
│ □ Team size and growth │
│ □ Enterprise customer count │
│ □ Geographic presence │
│ │
│ TECHNICAL SUSTAINABILITY Score: /10 │
│ ───────────────────────────────────────────────────────── │
│ □ Technology stack modernity │
│ □ API stability history │
│ □ Open source components (reduces lock-in) │
│ □ Data portability options │
│ │
│ ═════════════════════════════════════════════════════════ │
│ RISK LEVEL: │
│ 35-40: Low Risk 25-34: Medium Risk <25: High Risk │
└─────────────────────────────────────────────────────────────┘
Vendor Lock-in Assessment
interface LockInAssessment {
dataPortability: {
exportFormats: string[]; // JSON, CSV, SQL dump?
exportCompleteness: number; // % of data exportable
exportFrequency: string; // On-demand, scheduled?
exportCost: number; // Hidden fees?
migrationTools: boolean; // Official migration support?
};
contractualLockIn: {
minimumTerm: number; // Months
autoRenewal: boolean;
terminationNotice: number; // Days required
terminationFees: number;
priceIncreaseProtection: boolean;
};
technicalLockIn: {
proprietaryFormats: boolean;
customIntegrationDepth: number; // 1-10, how deep?
apiStandardsCompliance: boolean; // Uses standard protocols?
replacementDifficulty: number; // 1-10
};
operationalLockIn: {
userTrainingInvestment: number; // Hours invested
processIntegration: number; // 1-10, how embedded?
customWorkflowCount: number;
dependentSystems: string[];
};
// Calculate migration cost
estimatedMigrationCost: {
dataExtraction: number;
newSystemSetup: number;
dataMigration: number;
reintegration: number;
retraining: number;
parallelRunning: number; // Both systems during transition
total: number;
};
}
Exit Strategy Planning
Always plan your exit before signing:
┌─────────────────────────────────────────────────────────────┐
│ EXIT STRATEGY TEMPLATE │
├─────────────────────────────────────────────────────────────┤
│ │
│ VENDOR: _______________ CONTRACT START: ___________ │
│ │
│ DATA EXTRACTION │
│ ───────────────────────────────────────────────────────── │
│ Export mechanism: □ API □ Bulk export □ Support req │
│ Export format: ____________________________ │
│ Export completeness: ___% of data │
│ Export frequency: ____________________________ │
│ Data retention post-cancel: ___ days │
│ │
│ ALTERNATIVE VENDORS │
│ ───────────────────────────────────────────────────────── │
│ Primary alternative: ____________________________ │
│ Secondary alternative: ____________________________ │
│ Migration difficulty: □ Easy □ Medium □ Hard │
│ │
│ FALLBACK PLAN │
│ ───────────────────────────────────────────────────────── │
│ Can we build internally? □ Yes □ No │
│ Estimated build time: ___ months │
│ Interim solution: ____________________________ │
│ │
│ CONTRACTUAL PROTECTIONS │
│ ───────────────────────────────────────────────────────── │
│ □ Data export clause included │
│ □ Termination for convenience │
│ □ Price increase cap │
│ □ SLA with meaningful penalties │
│ □ Source code escrow (if critical) │
│ │
│ MIGRATION ESTIMATE │
│ ───────────────────────────────────────────────────────── │
│ Calendar time: ___ months │
│ Engineering effort: ___ person-months │
│ Estimated cost: $___________ │
│ │
└─────────────────────────────────────────────────────────────┘
Security and Compliance Evaluation
Security Assessment Checklist
┌─────────────────────────────────────────────────────────────┐
│ VENDOR SECURITY ASSESSMENT │
├─────────────────────────────────────────────────────────────┤
│ │
│ COMPLIANCE CERTIFICATIONS │
│ □ SOC 2 Type II (current, not expired) │
│ □ ISO 27001 │
│ □ Industry-specific (HIPAA, PCI-DSS, FedRAMP) │
│ □ GDPR compliance documentation │
│ │
│ DATA HANDLING │
│ □ Data residency options match your requirements │
│ □ Encryption at rest (AES-256 or better) │
│ □ Encryption in transit (TLS 1.2+) │
│ □ Key management (customer-managed keys option?) │
│ □ Data retention and deletion policies │
│ □ Backup and disaster recovery procedures │
│ │
│ ACCESS CONTROL │
│ □ SSO support (SAML, OIDC) │
│ □ MFA enforcement │
│ □ Role-based access control │
│ □ API key rotation │
│ □ Audit logging │
│ □ IP allowlisting │
│ │
│ SECURITY PRACTICES │
│ □ Penetration testing (annual, by third party) │
│ □ Bug bounty program │
│ □ Security incident response plan │
│ □ Vulnerability disclosure policy │
│ □ Security changelog/advisories │
│ │
│ INFRASTRUCTURE │
│ □ Cloud provider (AWS, GCP, Azure) │
│ □ Multi-region availability │
│ □ DDoS protection │
│ □ Network segmentation │
│ │
│ RED FLAGS │
│ ⚠ No SOC 2 or equivalent │
│ ⚠ Expired certifications │
│ ⚠ No SSO support │
│ ⚠ Customer data on shared infrastructure │
│ ⚠ Vague or missing security documentation │
│ ⚠ No incident response history/transparency │
│ │
└─────────────────────────────────────────────────────────────┘
Data Flow Security Analysis
Your System Vendor Boundary Vendor System
─────────────────────────────────────────────────────────────────────
┌─────────────┐ ┌─────────────┐ ┌─────────────────┐
│ Your │ │ Vendor │ │ Vendor │
│ Backend │───TLS──►│ API │───?───► │ Database │
│ │ │ Gateway │ │ │
└─────────────┘ └─────────────┘ └─────────────────┘
│ │ │
│ │ │
▼ ▼ ▼
Questions to Answer:
1. TRANSIT SECURITY
□ What encryption is used between your system and vendor?
□ Is certificate pinning available?
□ Are there any intermediate hops?
2. DATA AT REST
□ Where does your data physically reside?
□ What encryption protects stored data?
□ Who has access to encryption keys?
3. PROCESSING SECURITY
□ Is data processed in isolated environments?
□ Are there other customers on same infrastructure?
□ Is your data used for ML training or analytics?
4. DATA BOUNDARIES
□ What data actually needs to go to the vendor?
□ Can you minimize/anonymize sensitive fields?
□ Is there a data processing agreement (DPA)?
5. SUBPROCESSORS
□ Does vendor use subprocessors (AWS, Twilio, etc.)?
□ Are you notified of subprocessor changes?
□ Do subprocessors meet your security requirements?
The Decision Matrix
Weighted Decision Framework
interface DecisionMatrix {
// Define criteria and weights
criteria: {
name: string;
weight: number; // 0-100, total should = 100
evaluator: (option: Option) => number; // Returns 1-10 score
}[];
options: {
name: string;
type: 'build' | 'buy' | 'hybrid';
scores: Record<string, number>;
adjustments: {
reason: string;
impact: number; // -2 to +2
}[];
}[];
}
// Example implementation
const evaluateOptions = (matrix: DecisionMatrix): RankedOption[] => {
return matrix.options.map(option => {
const baseScore = matrix.criteria.reduce((total, criterion) => {
const score = option.scores[criterion.name] || 0;
return total + (score * criterion.weight / 100);
}, 0);
const adjustmentTotal = option.adjustments.reduce(
(total, adj) => total + adj.impact, 0
);
return {
name: option.name,
type: option.type,
baseScore,
adjustedScore: baseScore + adjustmentTotal,
details: {
criteriaScores: option.scores,
adjustments: option.adjustments
}
};
}).sort((a, b) => b.adjustedScore - a.adjustedScore);
};
Quick Decision Heuristics
For when you don't have time for full analysis:
┌─────────────────────────────────────────────────────────────┐
│ QUICK DECISION HEURISTICS │
├─────────────────────────────────────────────────────────────┤
│ │
│ STRONG BUILD SIGNALS │
│ ───────────────────────────────────────────────────────── │
│ ✓ Core differentiator for your business │
│ ✓ No existing solution meets >70% of requirements │
│ ✓ You have deep domain expertise │
│ ✓ You'll need to customize >50% of functionality │
│ ✓ Data sensitivity prevents external processing │
│ ✓ Scale requirements exceed vendor capabilities │
│ ✓ Long-term strategic asset │
│ │
│ STRONG BUY SIGNALS │
│ ───────────────────────────────────────────────────────── │
│ ✓ Commodity capability (auth, payments, email) │
│ ✓ Existing solution meets >80% of requirements │
│ ✓ Need to ship in <3 months │
│ ✓ Small team (<10 engineers total) │
│ ✓ Not a competitive differentiator │
│ ✓ Compliance requirements favor established vendors │
│ ✓ Build would require hiring for new expertise │
│ │
│ HYBRID INDICATORS │
│ ───────────────────────────────────────────────────────── │
│ ✓ Core requirement is commodity, but unique UX needed │
│ ✓ Buy for MVP, build later if proven valuable │
│ ✓ Buy the platform, build the integration layer │
│ ✓ Open source + managed hosting │
│ │
│ RED FLAGS - RECONSIDER DECISION │
│ ───────────────────────────────────────────────────────── │
│ ⚠ Building because "we can do it better" │
│ ⚠ Buying because "everyone uses it" │
│ ⚠ Team excited about building, not about problem │
│ ⚠ Buying to avoid learning something │
│ ⚠ Building to maintain control for control's sake │
│ ⚠ Decision driven by single stakeholder's preference │
│ │
└─────────────────────────────────────────────────────────────┘
Common Scenarios and Recommendations
Scenario 1: Authentication
┌─────────────────────────────────────────────────────────────┐
│ SCENARIO: USER AUTHENTICATION │
├─────────────────────────────────────────────────────────────┤
│ │
│ RECOMMENDATION: BUY (for 95% of companies) │
│ │
│ Why Buy: │
│ • Security-critical with severe downside risk │
│ • Rapidly evolving standards (passkeys, WebAuthn) │
│ • Compliance complexity (password policies, MFA) │
│ • Not a differentiator (users expect it to "just work") │
│ │
│ Options by Company Stage: │
│ ───────────────────────────────────────────────────────── │
│ Startup (<50 users): Firebase Auth, Supabase Auth │
│ Growth (50-10K users): Auth0, Clerk │
│ Scale (10K+ users): Okta, Auth0 Enterprise │
│ Enterprise (complex): Okta, Azure AD B2C │
│ │
│ Exceptions (Consider Building): │
│ • You ARE an identity company │
│ • Extreme customization of auth flow is core product │
│ • Government/classified requiring on-prem │
│ • Cost at massive scale (>10M MAU) │
│ │
└─────────────────────────────────────────────────────────────┘
Scenario 2: Payment Processing
┌─────────────────────────────────────────────────────────────┐
│ SCENARIO: PAYMENT PROCESSING │
├─────────────────────────────────────────────────────────────┤
│ │
│ RECOMMENDATION: BUY (for 99% of companies) │
│ │
│ Why Buy: │
│ • PCI compliance is expensive and complex │
│ • Fraud detection requires massive data │
│ • Bank/card network relationships take years │
│ • Regulatory landscape constantly changing │
│ │
│ Options by Use Case: │
│ ───────────────────────────────────────────────────────── │
│ Simple e-commerce: Stripe, Square │
│ Subscriptions: Stripe, Chargebee, Recurly │
│ Marketplace: Stripe Connect, PayPal Commerce │
│ B2B Invoicing: Stripe, Bill.com │
│ International: Adyen, Stripe (check coverage) │
│ │
│ Hybrid Approach: │
│ • Use payment provider APIs │
│ • Build custom checkout experience │
│ • Build billing/invoicing logic internally │
│ • Never store card numbers yourself │
│ │
│ Exceptions (Rare): │
│ • You ARE a fintech company │
│ • Volume justifies direct acquiring relationships │
│ • Specific markets with no good vendors │
│ │
└─────────────────────────────────────────────────────────────┘
Scenario 3: Search
┌─────────────────────────────────────────────────────────────┐
│ SCENARIO: SEARCH FUNCTIONALITY │
├─────────────────────────────────────────────────────────────┤
│ │
│ RECOMMENDATION: DEPENDS (evaluate carefully) │
│ │
│ Buy If: │
│ • Simple text search over products/content │
│ • Need search fast (<2 weeks) │
│ • Small dataset (<1M documents) │
│ • Standard relevance requirements │
│ │
│ Build/Self-Host If: │
│ • Search IS your product differentiator │
│ • Custom ranking algorithms needed │
│ • Very large scale (cost sensitivity) │
│ • Real-time indexing requirements │
│ │
│ Options: │
│ ───────────────────────────────────────────────────────── │
│ Fully Managed: Algolia, Elasticsearch Cloud │
│ Hybrid: Meilisearch Cloud, Typesense │
│ Self-Hosted: Elasticsearch, Meilisearch │
│ Database-Native: PostgreSQL FTS, MongoDB Atlas │
│ │
│ Decision Tree: │
│ │
│ Is search a core differentiator? │
│ │ │
│ ├── Yes → Build custom on Elasticsearch/Lucene │
│ │ │
│ └── No → Is dataset >10M docs? │
│ │ │
│ ├── Yes → Self-host Elasticsearch │
│ │ │
│ └── No → Algolia or Typesense Cloud │
│ │
└─────────────────────────────────────────────────────────────┘
Scenario 4: Analytics/Data Warehouse
┌─────────────────────────────────────────────────────────────┐
│ SCENARIO: ANALYTICS & DATA WAREHOUSE │
├─────────────────────────────────────────────────────────────┤
│ │
│ RECOMMENDATION: BUY (with build for custom layers) │
│ │
│ Modern Stack (Buy): │
│ ───────────────────────────────────────────────────────── │
│ Ingestion: Fivetran, Airbyte, Segment │
│ Warehouse: Snowflake, BigQuery, Databricks │
│ Transform: dbt (open source + Cloud) │
│ BI: Looker, Metabase, Preset │
│ │
│ Build Custom: │
│ • Data models specific to your domain │
│ • Custom metrics and KPIs │
│ • Product-specific analytics features │
│ • Real-time dashboards embedded in product │
│ │
│ Cost Considerations: │
│ • Snowflake/BigQuery: Usage-based, can spike │
│ • Set up cost monitoring and alerts │
│ • Consider Clickhouse for high-volume event data │
│ │
│ Self-Host Options (Cost Optimization): │
│ • Clickhouse for event data │
│ • PostgreSQL + TimescaleDB for time series │
│ • Apache Superset for BI │
│ │
└─────────────────────────────────────────────────────────────┘
Scenario 5: CRM
┌─────────────────────────────────────────────────────────────┐
│ SCENARIO: CRM / CUSTOMER DATA PLATFORM │
├─────────────────────────────────────────────────────────────┤
│ │
│ RECOMMENDATION: BUY (almost always) │
│ │
│ Why Buy: │
│ • Massive feature set takes years to replicate │
│ • Sales team already knows Salesforce/HubSpot │
│ • Integration ecosystem (1000s of apps) │
│ • Not a technical differentiator │
│ │
│ Options by Stage: │
│ ───────────────────────────────────────────────────────── │
│ Early Stage: HubSpot Free, Pipedrive │
│ Growth: HubSpot, Salesforce Essentials │
│ Enterprise: Salesforce, Microsoft Dynamics │
│ Product-Led: Segment + custom │
│ │
│ Common Mistake: │
│ "We'll build a simple CRM, it's just contacts" │
│ → 2 years later: You've built 10% of HubSpot poorly │
│ │
│ Build Custom Only If: │
│ • CRM functionality IS your product │
│ • Extremely specific vertical requirements │
│ • Need deep integration with real-time product data │
│ │
│ Hybrid Approach: │
│ • Buy CRM for sales team │
│ • Build customer data layer in your product │
│ • Sync via integration (Segment, reverse ETL) │
│ │
└─────────────────────────────────────────────────────────────┘
Negotiation and Contract Considerations
Negotiation Leverage Points
┌─────────────────────────────────────────────────────────────┐
│ VENDOR NEGOTIATION PLAYBOOK │
├─────────────────────────────────────────────────────────────┤
│ │
│ YOUR LEVERAGE INCREASES WHEN: │
│ ───────────────────────────────────────────────────────── │
│ • End of vendor's quarter/year │
│ • You have a credible alternative │
│ • You're a known brand (reference customer value) │
│ • Multi-year commitment possible │
│ • You're buying multiple products │
│ • You can provide case study/testimonial │
│ • You're in a strategic market for them │
│ │
│ NEGOTIABLE ITEMS (beyond price): │
│ ───────────────────────────────────────────────────────── │
│ • Implementation support hours │
│ • Training sessions │
│ • Premium support tier │
│ • Contract length flexibility │
│ • Price lock / cap on increases │
│ • Custom SLA terms │
│ • Data export guarantees │
│ • Termination for convenience │
│ • Audit rights │
│ • Custom feature development │
│ │
│ TYPICAL DISCOUNT RANGES: │
│ ───────────────────────────────────────────────────────── │
│ Annual vs Monthly: 10-20% │
│ Multi-year (2-3): 15-30% │
│ Startup/Growth programs: 50-90% (year 1) │
│ Enterprise deals: 20-40% off list │
│ End of quarter: Additional 10-20% │
│ │
└─────────────────────────────────────────────────────────────┘
Critical Contract Clauses
┌─────────────────────────────────────────────────────────────┐
│ CONTRACT CLAUSE CHECKLIST │
├─────────────────────────────────────────────────────────────┤
│ │
│ MUST HAVE │
│ ───────────────────────────────────────────────────────── │
│ □ Data ownership clause (you own your data) │
│ □ Data export rights (format and frequency) │
│ □ Termination for convenience (with reasonable notice) │
│ □ SLA with meaningful credits │
│ □ Security and compliance commitments │
│ □ Breach notification requirements │
│ □ Subprocessor notification │
│ □ Price increase cap (e.g., max 5% annual) │
│ │
│ IMPORTANT │
│ ───────────────────────────────────────────────────────── │
│ □ Auto-renewal terms (opt-out period) │
│ □ Service modification notification │
│ □ API deprecation policy │
│ □ Support response time commitments │
│ □ Disaster recovery commitments │
│ □ Insurance requirements │
│ │
│ NICE TO HAVE │
│ ───────────────────────────────────────────────────────── │
│ □ Most favored customer clause │
│ □ Source code escrow (for critical systems) │
│ □ Custom development commitments │
│ □ Early access to new features │
│ □ Dedicated success manager │
│ │
│ RED FLAG CLAUSES │
│ ───────────────────────────────────────────────────────── │
│ ⚠ Vendor can change terms with minimal notice │
│ ⚠ No data export rights │
│ ⚠ Long auto-renewal with short opt-out window │
│ ⚠ Unlimited price increases │
│ ⚠ Vendor owns derived/aggregate data │
│ ⚠ Forced arbitration in vendor's jurisdiction │
│ │
└─────────────────────────────────────────────────────────────┘
Common Mistakes and Anti-Patterns
The Build Trap
┌─────────────────────────────────────────────────────────────┐
│ BUILD TRAP ANTI-PATTERNS │
├─────────────────────────────────────────────────────────────┤
│ │
│ "NOT INVENTED HERE" SYNDROME │
│ ───────────────────────────────────────────────────────── │
│ Pattern: "We can build something better" │
│ Reality: You probably can't, and definitely shouldn't │
│ Signs: Engineers excited about the tech, not the │
│ problem; dismissing existing solutions │
│ Fix: Require proof of differentiation value │
│ │
│ "CUSTOMIZATION CREEP" │
│ ───────────────────────────────────────────────────────── │
│ Pattern: "We just need a few customizations" │
│ Reality: Those customizations become the whole project │
│ Signs: Requirements grow during evaluation │
│ Fix: Lock requirements before decision; MVP mindset │
│ │
│ "FUTURE-PROOFING FALLACY" │
│ ───────────────────────────────────────────────────────── │
│ Pattern: "We might need X in 2 years" │
│ Reality: You probably won't, or needs will change │
│ Signs: Decisions based on hypothetical requirements │
│ Fix: Decide based on known needs + easy migration │
│ │
│ "SUNK COST CONTINUATION" │
│ ───────────────────────────────────────────────────────── │
│ Pattern: "We've already built 60%, let's finish" │
│ Reality: Sometimes stopping is the right call │
│ Signs: Project dragging on, requirements changing │
│ Fix: Regular build vs buy re-evaluation checkpoints │
│ │
│ "RESUME-DRIVEN DEVELOPMENT" │
│ ───────────────────────────────────────────────────────── │
│ Pattern: Engineers want to build for experience │
│ Reality: Not aligned with business needs │
│ Signs: Tech choices driven by "interesting" not │
│ "appropriate" │
│ Fix: Separate learning projects from production │
│ │
└─────────────────────────────────────────────────────────────┘
The Buy Trap
┌─────────────────────────────────────────────────────────────┐
│ BUY TRAP ANTI-PATTERNS │
├─────────────────────────────────────────────────────────────┤
│ │
│ "DEMO-DRIVEN DECISIONS" │
│ ───────────────────────────────────────────────────────── │
│ Pattern: Choosing based on impressive demo │
│ Reality: Demos show best case, not your case │
│ Signs: Decision after one demo; no POC │
│ Fix: Always do technical POC with your data │
│ │
│ "SHINY OBJECT SYNDROME" │
│ ───────────────────────────────────────────────────────── │
│ Pattern: Buying the "hot" tool everyone's using │
│ Reality: Popularity != fit for your needs │
│ Signs: "Everyone uses X"; no requirements analysis │
│ Fix: Start with requirements, then evaluate options │
│ │
│ "FALSE ECONOMY" │
│ ───────────────────────────────────────────────────────── │
│ Pattern: Choosing cheapest option │
│ Reality: Integration/customization costs exceed savings │
│ Signs: Decision driven primarily by price │
│ Fix: Full TCO analysis including integration costs │
│ │
│ "VENDOR LOCK-IN BLINDNESS" │
│ ───────────────────────────────────────────────────────── │
│ Pattern: Ignoring future migration difficulty │
│ Reality: Lock-in costs compound over time │
│ Signs: No exit strategy; deep proprietary integration │
│ Fix: Always plan exit; prefer standard integrations │
│ │
│ "CHECKBOX EVALUATION" │
│ ───────────────────────────────────────────────────────── │
│ Pattern: "It has feature X, so we're good" │
│ Reality: Feature existence != feature quality │
│ Signs: Evaluation based on feature lists only │
│ Fix: Test actual workflows with real scenarios │
│ │
│ "DELEGATION OF STRATEGY" │
│ ───────────────────────────────────────────────────────── │
│ Pattern: Outsourcing strategic capability entirely │
│ Reality: Lose ability to differentiate │
│ Signs: Core value prop depends on vendor capability │
│ Fix: Keep strategic capabilities in-house or hybrid │
│ │
└─────────────────────────────────────────────────────────────┘
The Evaluation Process
Structured Evaluation Timeline
WEEK 1-2: REQUIREMENTS & SHORTLIST
══════════════════════════════════════════════════════════════
Day 1-3: Requirements gathering
• Stakeholder interviews
• Document must-have vs nice-to-have
• Define success criteria
Day 4-7: Market scan
• Identify 8-12 potential solutions
• Initial screening against must-haves
• Include "build" as an option
Day 8-10: Shortlist creation
• Reduce to 3-4 options (including build if viable)
• Initial vendor outreach
• Gather pricing ballparks
WEEK 3-4: DEEP EVALUATION
══════════════════════════════════════════════════════════════
Day 11-14: Technical deep-dive
• API documentation review
• Architecture assessment
• Security questionnaire
• Integration complexity analysis
Day 15-18: Hands-on POC
• Build prototype integration
• Test with realistic data
• Stress test if relevant
• Identify gaps and workarounds
Day 19-21: Vendor discussions
• Technical Q&A sessions
• Roadmap discussions
• Reference customer calls
• Support experience test
WEEK 5: ANALYSIS & DECISION
══════════════════════════════════════════════════════════════
Day 22-24: Analysis
• Complete TCO models
• Finalize evaluation matrix
• Document pros/cons/risks
• Draft recommendation
Day 25-28: Decision
• Stakeholder review
• Final vendor negotiations
• Contract review (legal)
• Decision and commitment
POST-DECISION
══════════════════════════════════════════════════════════════
Week 6+: • Contract finalization
• Integration planning
• Team communication
• Implementation kickoff
POC Checklist
┌─────────────────────────────────────────────────────────────┐
│ PROOF OF CONCEPT CHECKLIST │
├─────────────────────────────────────────────────────────────┤
│ │
│ PREPARATION │
│ □ Define specific POC objectives │
│ □ Identify 3-5 key scenarios to test │
│ □ Prepare realistic test data │
│ □ Set up isolated test environment │
│ □ Define success criteria (quantitative) │
│ □ Allocate dedicated engineer time │
│ │
│ TECHNICAL VALIDATION │
│ □ Test core use case end-to-end │
│ □ Test edge cases relevant to your domain │
│ □ Test integration with existing systems │
│ □ Test error handling and failure modes │
│ □ Measure actual performance (latency, throughput) │
│ □ Test at projected scale (2-3x current) │
│ │
│ OPERATIONAL VALIDATION │
│ □ Test monitoring and alerting │
│ □ Test support responsiveness │
│ □ Review documentation quality │
│ □ Test data export capability │
│ □ Evaluate admin/config experience │
│ │
│ RED FLAGS DURING POC │
│ ⚠ Documentation doesn't match behavior │
│ ⚠ Support is slow or unhelpful │
│ ⚠ "That feature is coming soon" for key needs │
│ ⚠ Requires more customization than expected │
│ ⚠ Performance significantly worse than stated │
│ │
└─────────────────────────────────────────────────────────────┘
Organizational Considerations
Stakeholder Alignment
Different stakeholders have different priorities:
┌─────────────────────────────────────────────────────────────┐
│ STAKEHOLDER PERSPECTIVE MAP │
├─────────────────────────────────────────────────────────────┤
│ │
│ STAKEHOLDER PRIORITIES CONCERNS │
│ ───────────────────────────────────────────────────────── │
│ │
│ Engineering • Technical elegance • Tech debt │
│ • Developer experience • Maintenance │
│ • Integration ease • Lock-in │
│ │
│ Product • Feature velocity • Roadmap delays │
│ • User experience • Feature gaps │
│ • Customization • Dependency │
│ │
│ Finance • Total cost • Budget surprises │
│ • Predictability • Hidden costs │
│ • ROI • Overruns │
│ │
│ Security • Compliance • Data exposure │
│ • Control • Vendor risk │
│ • Audit trail • Certifications │
│ │
│ Operations • Reliability • Incidents │
│ • Support quality • Complexity │
│ • Monitoring • On-call burden │
│ │
│ Executives • Strategic alignment • Execution risk │
│ • Competitive edge • Opportunity cost │
│ • Time to market • Reversibility │
│ │
└─────────────────────────────────────────────────────────────┘
Alignment Strategy:
• Identify top 2 concerns for each stakeholder
• Address concerns directly in recommendation
• Get buy-in from each group before final decision
• Document trade-offs transparently
Communication Template
# Build vs Buy Decision: [Capability Name]
## Executive Summary
**Recommendation:** [BUILD / BUY: Vendor Name / HYBRID]
**Confidence:** [HIGH / MEDIUM / LOW]
**Timeline Impact:** [Positive/Neutral/Negative + explanation]
**Cost Impact:** [X-year TCO comparison summary]
## Context
[2-3 sentences on why this decision is needed now]
## Options Evaluated
| Option | Fit Score | 3-Year TCO | Time to Value | Risk |
|--------|-----------|------------|---------------|------|
| Build | X/10 | $XXX,XXX | X months | [H/M/L] |
| Vendor A | X/10 | $XXX,XXX | X months | [H/M/L] |
| Vendor B | X/10 | $XXX,XXX | X months | [H/M/L] |
## Recommendation Rationale
[3-5 bullets on why this option]
## Key Risks and Mitigations
| Risk | Impact | Likelihood | Mitigation |
|------|--------|------------|------------|
| ... | H/M/L | H/M/L | ... |
## Trade-offs Accepted
[What we're giving up with this choice]
## Exit Strategy
[How we could change course if needed]
## Next Steps
1. [Immediate action]
2. [Timeline item]
3. [Who's responsible for what]
When to Revisit Decisions
Decision Review Triggers
┌─────────────────────────────────────────────────────────────┐
│ WHEN TO REVISIT BUILD VS BUY │
├─────────────────────────────────────────────────────────────┤
│ │
│ SCHEDULED REVIEWS │
│ ───────────────────────────────────────────────────────── │
│ • Annual vendor review (align with renewal) │
│ • Major version upgrades │
│ • Contract renewal periods │
│ • Strategic planning cycles │
│ │
│ EVENT TRIGGERS │
│ ───────────────────────────────────────────────────────── │
│ • Significant price increase (>20%) │
│ • Major outage affecting your business │
│ • Vendor acquisition or leadership change │
│ • Security incident at vendor │
│ • Feature deprecation affecting you │
│ • New competitor emerges in market │
│ • Your requirements change significantly │
│ │
│ SCALE TRIGGERS │
│ ───────────────────────────────────────────────────────── │
│ • Usage crosses pricing tier threshold │
│ • Team grows past certain size │
│ • Revenue/usage 10x from decision time │
│ • Geographic expansion requiring new capabilities │
│ │
│ STRATEGIC TRIGGERS │
│ ───────────────────────────────────────────────────────── │
│ • Capability becomes core differentiator │
│ • Acquisition or major pivot │
│ • New compliance requirements │
│ • Market dynamics shift significantly │
│ │
└─────────────────────────────────────────────────────────────┘
Migration Decision Framework
When current solution becomes problematic:
Step 1: Quantify the Pain
─────────────────────────
• What's the actual cost of current issues?
• How much time is spent on workarounds?
• What opportunities are we missing?
• Is this getting better or worse over time?
Step 2: Evaluate True Migration Cost
────────────────────────────────────
• Data migration complexity
• Integration rebuilding
• User retraining
• Parallel running period
• Risk of migration issues
• Opportunity cost during migration
Step 3: Compare Pain vs Migration Cost
──────────────────────────────────────
HIGH │ ┌─────────────┬─────────────┐
│ │ CONSIDER │ MIGRATE │
PAIN │ │ MIGRATE │ NOW │
│ ├─────────────┼─────────────┤
│ │ STAY & │ EVALUATE │
LOW │ │ OPTIMIZE │ CAREFULLY │
│ └─────────────┴─────────────┘
│ LOW HIGH
└─────────────────────────────────►
MIGRATION COST
Quadrant Actions:
• High Pain + High Cost: Plan carefully, migrate
• High Pain + Low Cost: Migrate quickly
• Low Pain + High Cost: Stay and optimize
• Low Pain + Low Cost: Evaluate, may migrate opportunistically
Conclusion: The Decision Principles
┌─────────────────────────────────────────────────────────────┐
│ BUILD VS BUY: CORE PRINCIPLES │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. BUILD WHAT DIFFERENTIATES, BUY WHAT DOESN'T │
│ Your engineering time is precious. Spend it on what │
│ creates competitive advantage, not on reinventing │
│ infrastructure. │
│ │
│ 2. TOTAL COST > STICKER PRICE │
│ Account for maintenance, opportunity cost, and │
│ hidden expenses. The $10K vendor vs $50K build │
│ rarely tells the full story. │
│ │
│ 3. PLAN YOUR EXIT BEFORE YOU ENTER │
│ Every buy decision should include an exit strategy. │
│ If you can't migrate away, you can't negotiate │
│ effectively. │
│ │
│ 4. REQUIREMENTS BEFORE SOLUTIONS │
│ Gather requirements first, then evaluate options. │
│ Don't let vendor demos drive your requirements. │
│ │
│ 5. POC > PROMISES │
│ Never trust feature lists. Always validate with a │
│ hands-on proof of concept using your actual data. │
│ │
│ 6. DECISIONS ARE TEMPORARY │
│ Build vs buy isn't permanent. What you buy today, │
│ you might build tomorrow (and vice versa). Design │
│ for change. │
│ │
│ 7. ALIGN STAKEHOLDERS EXPLICITLY │
│ Different teams have different priorities. Surface │
│ and address these before, not after, the decision. │
│ │
│ 8. DOCUMENT YOUR REASONING │
│ Future you will wonder why this decision was made. │
│ Write it down with context, alternatives, and │
│ trade-offs accepted. │
│ │
└─────────────────────────────────────────────────────────────┘
Quick Reference Card
┌─────────────────────────────────────────────────────────────┐
│ BUILD VS BUY QUICK REFERENCE │
├─────────────────────────────────────────────────────────────┤
│ │
│ QUICK SCORE (answer yes/no for each) │
│ │
│ BUILD POINTS: BUY POINTS: │
│ □ Core differentiator? (+3) □ Commodity? (+3) │
│ □ Deep customization? (+2) □ Need speed? (+2) │
│ □ Have expertise? (+2) □ Small team? (+2) │
│ □ Data sensitivity? (+2) □ Compliance need? (+2) │
│ □ Scale limits vendor? (+1) □ Proven solutions? (+1) │
│ │
│ Total: ___ Total: ___ │
│ │
│ Higher score wins (tie → buy, unless strategic) │
│ │
│ ───────────────────────────────────────────────────────── │
│ │
│ TCO QUICK ESTIMATE │
│ │
│ Build: Initial dev × 3 (for true 3-year cost) │
│ + $287K/year per dedicated engineer │
│ │
│ Buy: Annual subscription × 3 │
│ + Integration cost × 1.5 │
│ + 10% annual for administration │
│ │
│ ───────────────────────────────────────────────────────── │
│ │
│ RED FLAGS CHECKLIST │
│ │
│ Build: □ "We can do it better" │
│ □ No one has built this before │
│ □ Team excited about tech, not problem │
│ │
│ Buy: □ No POC, just demos │
│ □ Choosing cheapest option │
│ □ No exit strategy │
│ │
└─────────────────────────────────────────────────────────────┘
The best architects don't have a bias toward building or buying—they have a bias toward solving problems effectively. Sometimes that means writing code. Sometimes it means writing a check. Knowing which is which separates good architects from great ones.
What did you think?