Build vs Buy / Outsourcing vs Capacity Planning

Definition

The build vs buy decision determines whether you develop a capability in-house or outsource/purchase it. The core rule: build what's core to your competitive advantage, buy everything else. Building a custom CRM when your business is e-commerce wastes engineering on undifferentiated work. Slack built their messaging infra (core advantage) but bought Stripe for payments (commodity). Companies that misallocate build/buy decisions waste 20-30% of engineering capacity on projects that off-the-shelf tools handle better.

Common trap

The 'Not Invented Here' syndrome is deadly — engineering teams believe they can build a better version of existing tools. Custom-built billing systems, authentication, and analytics almost always cost 5-10x more than buying (SaaS fees for 5 years vs. building + maintaining). Hidden costs include: ongoing maintenance (20% of build cost annually), security patches, onboarding new engineers to custom systems, and opportunity cost of engineers NOT building your core product. Conversely, over-outsourcing core capabilities makes you dependent on vendors who can raise prices or shut down.

Practical use

For each build/buy decision, calculate the Total Cost of Ownership (TCO) over 3 years. For build: Development cost + (Annual maintenance × 3) + Opportunity cost of delayed core features. For buy: (Annual license × 3) + Integration cost + Switching cost risk. If the buy TCO is less than 50% of build TCO AND the capability isn't core to your competitive advantage, buy. Review all vendor contracts annually — a $500/month tool that your 5-person team used but your 50-person team outgrew becomes a scaling liability.

Formula

Definition

Capacity planning is the process of determining how much work your team can handle and aligning resources to demand. The core calculation is: Available Capacity = Team Size × Working Hours × Productivity Factor (typically 0.6-0.8 after meetings, admin, and context-switching). A team of 5 engineers working 40h/week at 70% productivity has 140 productive hours/week, not 200. Companies that do capacity planning well ship 35% more features per engineering dollar by eliminating both overwork (burnout → turnover) and underutilization (idle teams → wasted salary).

Common trap

The capacity trap is planning at 100% utilization. Organizations that load teams to 95-100% see throughput DECREASE by 20-30% because there's no buffer for bugs, urgent requests, sick days, or creative thinking. McKinsey's research shows optimal knowledge work utilization is 70-85% — above that, quality drops, bugs increase, and burnout skyrockets. Another trap: headcount-based planning. Adding 1 engineer doesn't add 1 engineer's worth of output — it adds 0.5-0.7 due to onboarding, mentoring overhead, and increased communication costs (Brooks's Law).

Practical use

Calculate your team's true capacity: (Number of ICs × Weekly Hours × Productivity Factor) - Planned meetings - On-call hours = Actual Weekly Capacity. Track velocity (story points or tickets completed) over 4-week rolling average. If actual output is consistently below 70% of theoretical capacity, audit where time goes — most teams lose 30-40% to meetings, Slack, and context-switching. Set a 'capacity budget': 70% planned work, 15% unplanned/bugs, 15% tech debt and improvements.

Formula