What is decide what to build vs. what to buy

The Real Problem Behind Build vs. Buy Decisions

Most founders frame build vs. buy as a resource allocation problem. You have limited time, money, and engineering capacity — so what deserves your internal effort versus external investment? This framing guarantees suboptimal decisions.

The real problem is constraint identification. Every business has exactly one bottleneck that determines its throughput at any given moment. Everything else is supporting infrastructure. When you understand your constraint, the build vs. buy decision becomes obvious.

Consider a B2B SaaS company hitting $5M ARR. They're debating whether to build a custom billing system or buy one off the shelf. If their constraint is customer acquisition (they can't generate enough qualified leads), building billing is pure waste. If their constraint is revenue expansion (they can't upsell existing customers due to billing limitations), building might be essential.

The constraint determines everything. Build what directly addresses it. Buy everything else.

Why Most Approaches Fail

Traditional decision frameworks focus on cost analysis, technical complexity, or strategic importance. These miss the point entirely. You end up optimizing secondary variables while your actual bottleneck remains untouched.

The "core competency" approach is especially destructive. Companies convince themselves they need to build customer support tools because "customer experience is our differentiator." Meanwhile, their real constraint is product-market fit for a specific segment, and they're burning runway on infrastructure.

You cannot optimize a system by optimizing its parts in isolation. The constraint dictates system performance, not the efficiency of individual components.

Another common trap: building because it seems cheaper upfront. You calculate developer hours versus software licensing costs and choose internal development. This ignores opportunity cost entirely. Those developer hours could eliminate your actual constraint instead of recreating commodity functionality.

The First Principles Approach

Start with constraint identification using the Five Whys technique adapted for business systems. Ask: "What prevents us from doubling our key metric in the next 90 days?" Keep drilling down until you hit something concrete and measurable.

For a marketplace business, this might look like: Can't double GMV → Not enough supply-side inventory → Suppliers can't manage orders efficiently → Our current vendor management tools create friction → Specific workflow bottlenecks in onboarding and order tracking.

Now you have clarity. If order management workflow is your constraint, you build tools that directly address it. Everything else — accounting software, email marketing platforms, analytics dashboards — you buy the best available solution and move on.

The decision matrix becomes binary: Does this directly address our constraint? Build it. Does this enable constraint-focused work? Buy the best available option.

The System That Actually Works

Create a three-tier classification system for every potential build vs. buy decision:

Tier 1 - Constraint Systems: These directly impact your bottleneck. Build these internally with your best people. Example: If your constraint is customer onboarding speed, build custom onboarding workflows that eliminate friction points specific to your process.

Tier 2 - Enabling Systems: These support Tier 1 work but aren't constraints themselves. Buy best-in-class solutions. Example: Project management tools, communication platforms, basic CRM functionality. Speed of implementation matters more than perfect fit.

Tier 3 - Commodity Systems: These are table stakes for operating a business. Always buy. Examples: Accounting software, payroll processing, basic security tools. Any energy spent here is energy not spent on your constraint.

The goal is not to build the perfect system. The goal is to remove the constraint faster than your competition.

Review this classification quarterly. As you solve constraints, new ones emerge. What was Tier 1 (constraint-focused) might become Tier 2 (enabling). Your build vs. buy decisions should evolve accordingly.

Common Mistakes to Avoid

The biggest trap is building solutions for imaginary future constraints. You're at $2M ARR worrying about systems that matter at $20M ARR. This is pure speculation disguised as strategic planning. Build for your current constraint, not your projected one.

Another mistake: perfectionism in bought solutions. You spend months evaluating 15 different CRM options when your constraint is product development speed. Good enough is good enough for non-constraint systems. Pick something reasonable and move on.

The sunk cost fallacy appears frequently here. You've already invested in building something that no longer addresses your constraint, but continue developing it because "we're already 80% done." Stop. Constraints shift. Your build vs. buy decisions should shift with them.

Finally, avoid the complexity trap of building integrations between bought solutions. If you need five different tools to work together seamlessly, you probably need one comprehensive solution instead. Don't build the plumbing between commodity systems — find better commodity systems.