Decide what to build vs. what to buy

The Real Problem Behind Build vs. Buy Decisions

You're staring at a spreadsheet comparing vendor costs, feature matrices, and implementation timelines. The decision feels impossible because you're solving the wrong problem.

Build vs. buy isn't about features or cost. It's about identifying your constraint. Most founders get trapped thinking they need more capabilities when they actually need to remove bottlenecks. You end up building complex systems that don't move the needle or buying expensive tools that create new problems.

The real question isn't "what should we build" — it's "what single thing, if improved, would increase our throughput the most?" Everything else is noise. Once you identify your constraint, the build vs. buy decision becomes obvious.

Here's what constraint theory tells us: any improvement not made at the constraint is an illusion. If your sales team can only handle 50 qualified leads per week, building a better lead generation system won't increase revenue. You'll just create a bigger backlog.

Why Most Approaches Fail

The typical build vs. buy framework asks the wrong questions. Teams compare feature lists, calculate ROI on paper, and debate "strategic value" in endless meetings. This creates three predictable traps.

First, the Complexity Trap. You assume more features equal better outcomes. So you build a custom solution with 47 features because the vendor only has 42. Six months later, your team uses 3 features and the system needs constant maintenance. The complexity you built to solve problems becomes the problem.

Second, the Vendor Trap. You buy a solution that promises to solve everything, then spend months configuring it to match your "unique" processes. The tool that was supposed to save time becomes a time sink. You're not buying a solution — you're buying someone else's complexity.

Most build vs. buy decisions fail because teams optimize for capabilities instead of constraints. You end up with powerful systems that don't improve the one thing that matters.

Third, the false urgency of completeness. Teams think they need a perfect solution before they can move forward. So they spend quarters evaluating options while their actual constraint — usually something simple like response time or data visibility — continues to limit growth.

The First Principles Approach

Strip away inherited assumptions and start with throughput. What's the single process that, if improved, would increase your output the most? Not what feels important or strategic — what actually determines your capacity.

Map your current process from input to output. Find the step with the longest queue or lowest capacity. That's your constraint. Everything else is supporting infrastructure. Your build vs. buy decision should focus exclusively on this constraint.

Now apply the constraint test: Will building this ourselves remove the constraint faster than buying? Will buying this remove the constraint without creating new ones? The answer depends on three factors: speed to constraint removal, risk of new bottlenecks, and cost of maintenance.

For example, if your constraint is data analysis speed and your team can build a custom dashboard in two weeks, build it. If the constraint is payment processing and compliance would take six months to implement, buy it. The decision framework is simple when you're optimizing for the right variable.

The System That Actually Works

Start with constraint identification. Map your process, measure cycle times, and find the slowest step. Don't guess — measure. Your constraint might not be where you think it is.

Apply the 80/20 rule to constraint removal. What's the minimum viable solution that removes 80% of the constraint? This becomes your build vs. buy criteria. If you can build that 80% solution in less time than it takes to evaluate, purchase, and implement a vendor solution, build it. If not, buy the simplest tool that removes the constraint.

Design for evolution, not perfection. Your constraint will change as you grow. Build systems that can be easily modified or replaced. Buy tools with good APIs and export capabilities. The worst decision is locking yourself into a solution that becomes your next constraint.

Test your constraint assumptions quickly. Build a prototype or run a pilot with a vendor trial. Don't spend months planning — spend weeks testing. You'll learn more from a week of real usage than a month of demos and documentation.

The best build vs. buy decisions optimize for speed of learning, not completeness of solution. Get to constraint removal fast, then iterate.

Common Mistakes to Avoid

Don't optimize for edge cases before you've solved the core constraint. Teams build complex systems to handle every possible scenario, then discover the edge cases rarely occur. Solve for the 80% case first. The edge cases can wait.

Avoid the "strategic asset" trap. Just because something feels important doesn't mean you should build it. Payment processing feels strategic, but building your own payment system won't differentiate your business. Your constraint is probably somewhere else entirely.

Don't underestimate maintenance costs. That custom solution you built in three weeks might need updates every month. Factor in the true cost of ownership — developer time, bug fixes, feature additions, and system updates. Sometimes the vendor's monthly fee is cheaper than your internal maintenance cost.

Finally, resist the sunk cost fallacy. If you realize you made the wrong decision, change course quickly. The cost of switching is usually less than the cost of persisting with a suboptimal solution. Your goal is constraint removal, not justifying past decisions.