Build vs buy: a decision framework for technical leaders

When should you build software instead of buying it?

Build when the capability is a source of competitive advantage, when no vendor fits your workflow without contorting it, or when the vendor economics break at your scale. Otherwise buy, and spend the saved time on the part customers actually pay for.

What is the true cost of building software in-house?

Take your engineering estimate and add ongoing maintenance at roughly 15–25% of the build cost per year, plus on-call, security patching, documentation and the features you did not ship instead. That last item is usually the largest and the least counted.

How do you reduce vendor lock-in when you buy?

Isolate the vendor behind your own interface and keep a copy of your data. Lock-in is rarely about the contract; it is about how many places in your codebase know the vendor's name.

What should you almost never build yourself?

Authentication, payments, email delivery, observability, and anything cryptographic. These are solved, heavily attacked problems where a mature vendor is safer and cheaper than your own second-best implementation.

Frequently asked questions

Is buying software always faster than building it?

Not always — integration and data migration can take longer than a naive build. But the vendor's timeline is bounded, whereas a build has an unbounded maintenance tail.

When does it make sense to replace a vendor with in-house software?

When the vendor's cost is growing faster than the revenue it supports, when their roadmap has diverged from your needs, or when the capability has become part of your differentiation.

How do you justify a build vs buy decision to a board?

Present a five-year total cost of ownership for both paths, the differentiation argument, and the risk of each. Boards accept 'we build what we sell and buy the rest' quickly when the numbers are attached.