“Don’t build what you can buy” is the right default and the wrong rule, because followed blindly it bends the one process you do better than anyone into the shape of a generic tool, and you pay for it every year. This post gives you the two questions that settle build vs buy, the four costs the comparison spreadsheet leaves out, a worked example with numbers, and the trap in the middle where most of the expensive projects live.
Two questions, asked in order
Strip the decision down and it is two questions, in this order; cost comes later. First: is this capability a differentiator, meaning something customers pay you for because you do it differently? Second, and only if the answer is yes: does a product fit it without heavy customizing?
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"| F(["Buy it, configure it, own the data"])
D -->|"No, you'd rebuild most of it"| E(["Build the thing that fits"])
- Buy when it’s a commodity. Payroll, email, accounting, HR records, a standard CRM, document signing. If a mature product covers 80% or more of what you need out of the box, buy it, and change your process to match the product rather than the other way round.
- Build when the process is the point. You build when the thing you’d build is the thing you do better than anyone else: the pricing logic that wins tenders, the scheduling engine that keeps your field teams busy, the client portal that is the reason customers stay. You also build when forcing a product to fit means customizing so much you’re building anyway, on someone else’s foundation. And you build when you need control of your data, your integrations, or your roadmap that a vendor will never hand you.
The honest version of the second question is a number: how much of the product would you change? Under a fifth, configure it and buy. Over half, you are already building, and you should decide to do it properly.
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.
How to tell configuration from customization:
- Configuration is what the product lets you change from a settings screen: fields, workflows, roles, templates, reports. It survives upgrades.
- Customization is code: custom modules, scripts inside the platform, database changes, integrations that bypass the vendor’s API. Every upgrade can break it, and only the people who wrote it can fix it.
- The tell is the statement of work. If the integrator’s proposal has more days under “development” than under “configuration and training”, you are buying a build with a licence fee attached.
Where your capability lands
Put each capability on two axes: how much of a differentiator it is, and how well a product fits it. The corners decide.
quadrantChart title Build, buy, or change the process x-axis Product fits poorly --> Product fits well y-axis Commodity --> Your differentiator quadrant-1 Buy, own the data and the exit quadrant-2 Build it quadrant-3 Change the process, then buy quadrant-4 Buy and move on "Payroll": [0.88, 0.12] "Accounting": [0.82, 0.2] "Standard CRM": [0.72, 0.32] "Tender pricing engine": [0.22, 0.86] "Client portal": [0.35, 0.74] "Field scheduling": [0.5, 0.58]
Bottom right: buy and move on. Top left: build. Top right: a product that fits something you care about, so buy it, but negotiate data export and exit terms before you sign, because it is now load-bearing. Bottom left is the one owners get wrong: a commodity no product fits usually means your process is odd for no good reason. Fix the process, then buy. The dots near the middle, like field scheduling, are where the customization trap lives.
The four costs the spreadsheet leaves out
Most build vs buy comparisons put the licence next to the build quote and stop. That is the smallest number in the deal, as we set out in the hidden costs of enterprise software. Four costs decide the real answer:
- Integration. Every product has to talk to your accounting system, your identity provider, and whatever it replaced. A build integrates the way you need; a product integrates the way the vendor allows.
- The upgrade tax. For a customized product, every vendor release is a small project: retest, patch, redeploy. For a build, you own the roadmap and the tax, and your team has to actually pay it.
- Data and residency. If the product is SaaS hosted outside the Kingdom, you have a cross-border transfer question before you have a contract. PDPL took effect on 14 September 2023, full compliance was required by 14 September 2024, SDAIA is the regulator, and cross-border transfer is governed by Article 29 and SDAIA’s Transfer Regulations (Morgan Lewis, 2024). If you are under NCA ECC as well, ask where the logs live too.
- Exit. What does it cost to leave? For a product: the data export format, the notice period, the migration. For a build: the handful of people who understand it. Price both at signing, while you still have leverage.
A worked example
Let’s put numbers on one. Say you are a building-materials distributor issuing 1,500 quotes a month, and your pricing logic (supplier tier times project size times delivery window) is the reason contractors come back. Two options.
Option A, buy a CRM with a quoting module: 120,000 riyals a year in licences, plus 300,000 to have an integrator encode your pricing logic as customizations, plus about 60,000 a year in rework every time the platform upgrades. Over three years that is roughly 840,000.
Option B, build a quoting engine that sits on top of a standard CRM: 600,000 to build, then about 80,000 a year to host, maintain, and keep one engineer familiar with it. Over three years, also 840,000.
The numbers are made up to show the shape, and the shape is the lesson. At year three the two lines cross. After that, A keeps paying 180,000 a year and B pays 80,000, and B owns the logic that wins the tenders. Now change one assumption: your pricing is standard, so the 300,000 in customization and the 60,000 of rework disappear. Buy wins by more than double, 360,000 against 840,000. Build only pays back when the thing you build is the thing that differentiates you.
Where build vs buy goes wrong
- Building because a competitor did. If the capability doesn’t win you customers, their build is their problem. You get the maintenance without the advantage.
- Underestimating the build. McKinsey and Oxford studied more than 5,400 IT projects and found that large ones run on average 45% over budget, 7% over time, and deliver 56% less value than predicted (McKinsey, 2012). A build quote without a contingency and a phased plan is a wish, not a plan. Our post on why software projects fail covers the causes.
- Buying, then customizing your way into a build. The trap above.
- Forgetting the same logic applies to AI. Off-the-shelf AI tools versus a custom model is the same question; we walk through it in off-the-shelf AI vs custom AI.
How to decide without betting the budget
The reliable pattern is boring. Pick one capability, not the whole estate. Write down, in plain language, the twenty things it must do, and mark which five are the reason customers choose you. Run two or three products against that list in a two-week trial with real data, and count what they do out of the box versus what needs code. If the differentiator items are covered by configuration, buy. If they need customization, get one honest build estimate with a phased plan, price the four hidden costs on both sides, and compare the three-year number, not the sticker. Then decide, and write down why.
The right answer is almost always a portfolio. Buy the commodity. Build the differentiator. Wire the two together cleanly through the product’s API, not through changes inside it, so each can be replaced without touching the other. An independent technology assessment is the fastest way to get the split right the first time.
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.