“Don’t build what you can buy” is a good default. Off-the-shelf software is cheaper to start, faster to deploy, and someone else maintains it. But follow that rule blindly and you end up bending your best, most distinctive processes to fit a generic tool, and paying to do it forever.
So the real question isn’t build or buy. It’s this: where does building give you a durable advantage, and where is it just expensive reinvention?
Buy when it’s a commodity.
Some capabilities give you nothing by being different. Payroll. Email. Accounting. Standard CRM. If a mature product covers 80% or more of what you need without heavy customizing, buy it. Especially when speed matters more than fit and the process isn’t where you win.
Build when the process is the point.
You build when the thing you’d build is the thing you do better than anyone else. When no product fits, and forcing one means customizing so much you’re basically building anyway, just on someone else’s foundation. When you need control over your data, your integrations, or your roadmap that a vendor will never hand you. Or when lock-in on a core system is a risk you can’t accept.
The trap is the middle.
Watch out for “let’s just customize the off-the-shelf one.” It looks like buying and quietly turns into building, except on a platform you don’t control, with upgrades that keep snapping your customizations. A lot of the most painful enterprise projects live right here, and ERP is the classic example: Gartner has reported that a large share of ERP initiatives fail to meet their intended business goals, often because the product never really fit the business in the first place. If you’re about to customize 60% of a product, you owe yourself an honest look at building the 100% that actually fits.
Here’s the whole decision boiled down to two questions you ask in order.
flowchart TD
A(["A capability you need"]) --> B{"Is this your differentiator?"}
B -->|"No, it's a commodity"| C(["Buy it and move on"])
B -->|"Yes"| D{"Does a product fit without heavy customizing?"}
D -->|"Yes"| C
D -->|"No, you'd rebuild most of it"| E(["Build the thing that fits"])
A simple test: own it or rent it?
Would you rather own this capability outright, or rent it? For commodity functions, rent. For the systems that are your business, owning the software, and the people who understand it, is usually the cheaper path over time, even when the upfront number looks bigger.
The right answer is almost always a portfolio. Buy the commodity. Build the differentiator. Wire the two together cleanly.
Stuck between a product that almost fits and a build you’re nervous to start? SDCG gives you independent build vs buy assessments, and because we’re the engineers who’d actually deliver the build, the advice is grounded in what shipping it really takes. We don’t resell software, so we have no reason to push you either way. Book a free 30-minute review.