How decide what to build vs. what to buy

The Real Problem Behind To Issues

Most founders think they're deciding between build vs. buy. They're not. They're actually deciding between control vs. speed, but they frame it wrong.

When you build, you get complete control over the system — how it works, how it integrates, how it evolves. When you buy, you get speed — someone else solved the problem, you just need to implement their solution.

The real problem isn't the decision itself. It's that you're making this choice without understanding which constraint actually limits your throughput. You're optimizing for the wrong variable.

Most build vs. buy decisions happen reactively. Your current system breaks, someone pitches a vendor solution, your team wants to build something custom. None of these triggers help you understand what actually moves the needle for your business.

Why Most Approaches Fail

The standard approach is to list pros and cons. Build gives you flexibility. Buy gives you speed. Build costs more upfront. Buy creates vendor dependency. This framework is useless because it treats all factors as equally important.

They're not. In any system, only one constraint determines throughput. Everything else is noise.

The fastest way to slow down is to optimize multiple things simultaneously. Pick the one thing that matters most and ignore everything else until it's solved.

The second failure is the Complexity Trap. Teams assume that building means creating something sophisticated and custom. So they compare a complex custom solution against a simple vendor tool. Of course the vendor wins — they're not comparing equivalent options.

The third failure is timeline thinking. Teams ask "What's faster right now?" instead of "What compounds over time?" A vendor solution might be faster this quarter, but if it creates integration debt or forces workarounds, you'll pay that cost every quarter forever.

The First Principles Approach

Start with constraint identification. What single factor limits your ability to grow? Not what's broken or annoying — what actually constrains throughput.

If your constraint is execution speed, buy beats build almost every time. You need to move fast, and vendor solutions give you that speed. Your competitive advantage isn't in solving this particular problem — it's in applying the solution faster than competitors.

If your constraint is differentiation, build usually wins. When your unique value proposition depends on how you solve this specific problem, you can't outsource it. The system becomes part of your moat.

If your constraint is integration complexity, the decision becomes more nuanced. You need to understand the total system cost, not just the component cost. A vendor tool that requires three other tools to work properly isn't simpler than building one integrated solution.

Map your constraint to the decision framework. Don't optimize for secondary factors until you've solved the primary constraint.

The System That Actually Works

The decision framework has four steps, applied in order.

Step 1: Constraint mapping. Identify the single factor that limits growth. Use constraint theory — find the bottleneck that determines system throughput. This constraint drives the entire decision.

Step 2: Time horizon analysis. Different constraints require different time horizons. Execution speed constraints need solutions now. Differentiation constraints can wait for the right solution. Integration constraints need solutions that compound over time.

Step 3: System complexity assessment. Count the total number of components, not just the new one. A vendor solution that requires integration with four other systems is more complex than building one integrated system. Map the real complexity.

Step 4: Compounding analysis. Ask which solution gets better over time with the same input. Custom solutions can compound as your team learns and improves them. Vendor solutions rarely compound — they often get worse as they add features you don't need.

The best build vs. buy decisions create compounding systems — solutions that improve automatically as your business grows.

Apply this framework to every component decision. Don't batch them together. Each component should be evaluated against your specific constraint and system requirements.

Common Mistakes to Avoid

The biggest mistake is scope creep in building. You decide to build a simple solution, then gradually add features until you've recreated enterprise software. If you're going to build, build the minimum viable system that solves your constraint. Nothing more.

The second mistake is vendor dependency blindness. You choose a vendor solution without understanding the switching costs. When that vendor changes pricing, discontinues features, or gets acquired, you're trapped. Map the dependency risk before you commit.

The third mistake is team capability mismatch. You decide to build something your team can't actually build well. Building only works if you can execute better than vendors. If you can't, you're just choosing expensive customization over proven solutions.

The fourth mistake is integration debt accumulation. Each vendor tool creates integration points. Each integration point creates maintenance overhead. You end up spending more time connecting systems than building value. Count the total integration cost, not just the tool cost.

Remember: this isn't a one-time decision. Your constraint changes as your business grows. The right answer for a 10-person company is different from the right answer for a 100-person company. Revisit these decisions when your constraint shifts.