Artifact §04 · Method

Build or buy, worked through

Build or buy is one of the few decisions a company makes once and then lives with for a decade. This is how I would run it, worked through on an illustrative case: a mid-sized consumer goods manufacturer replacing seven separate systems with one. What the decision turns on, the four criteria I would weight before any demo, how the cost model works, the order the dependencies set, and the one module I would buy rather than build.

Like the three pieces in the worked example, the company here is illustrative, and so are the numbers, which are indexed rather than real. The reasoning is the part I would stand behind in a steering meeting, and where it differs from what a vendor deck would tell you, that is the point.

The case

Company: A consumer goods manufacturer with seven business functions, each on its own system or spreadsheet. Illustrative.
Functions: Inventory, production planning, order tracking, sales, procurement, HR, finance
Already built: An in-house payroll system, delivered two years earlier by the same engineering team: salary processing, attendance, deductions, and tax compliance.
Requirements: One specification set across all seven functions, with competing needs reconciled before anyone builds. Where two functions define the same thing differently, the definition is settled in writing first.
The question: Buy a package, or build on the team that already shipped payroll.

What the decision turns on

Start from what each of the seven functions needs, not from what a vendor demo covers. That order matters. A demo is built to make time to deploy feel like the only criterion, and it is very good at it. Written down first, the requirements show where the company's way of working is ordinary and where it is not, and the parts that are not ordinary are the parts a package needs custom work to follow.

Once that custom work is priced as a number rather than described as an adjective, buying often stops looking like the safe option. It does not remove the software risk or the timeline risk; it can put a licence bill on top of both. When the numbers say build, the system that results follows the factory instead of the other way round, on a roadmap the company controls, and it integrates natively with the systems already there.

The options a manufacturer that size has on the table

A tier-one packaged ERP through an implementation partner

The benchmark, and the option most people in the room expect to choose. The partner does the implementation and the customization, at partner rates, and the licence is billed every year in US dollars.
A modular, open-core ERP

Quicker to stand up and cheaper to enter, with the customization done in house or by a partner. The serious alternative to the tier-one option rather than the cheap one.
A domestic package built around Canadian tax and payroll rules

Stronger on compliance than either international option, weaker on the factory floor.
Build it, with a team that has already shipped

In this case the in-house engineering team exists, has delivered payroll, and knows the business. The question is whether that is enough, and the honest answer is: for some modules, yes, and for one, no.

Four criteria, weighted before anyone sees a demo

This is how I would weight the decision, and the order I would insist on: weights agreed and written down before the first demo, so the demo cannot reset them.

Criterion	What to establish	Usually favours
1. Fit to how the factory works today	Multi-stage bills of materials, scrap allowances, batch routing that changes by the day, wages tied to what comes off the line. The question is what share of that logic a package follows out of the box, and the answer has to be a percentage, not "some configuration".	Build, where the share is large
2. Five-year cost, and currency risk	Partner fees up front, then per-user licences billed every year in US dollars against revenue earned in Canadian dollars. In-house engineering time costs a fraction of either and does not move with the exchange rate.	Build
3. Fit with the systems you already have	Attendance, labour costing and deductions have to flow between payroll and the ERP. Integration code gets written either way; the difference is who writes it and at what rate. This criterion favours build by construction, so it gets a lower weight, not a free pass.	Build, weighted down
4. Time to deploy, and disruption	Packages promise a core ledger in six to eight months. A build carries real timeline risk, and the evaluation should say so in writing rather than pretend otherwise. This is the criterion that bites later, and it is the one that favours buying.	Buy

The cost model, illustrated

Illustrative. These are round numbers chosen to show how the comparison works, indexed so that the packaged option's five-year cost is 100. The shape is what matters: a package moves cost into licences and partner customization, and a build moves it into internal time and the years after go-live.

Five-year cost line	Packaged, illustrative	Build, illustrative
Licences, five years	35	0
Implementation partner	25	0
Custom work the package still needs	25	0
Internal build time, fully loaded	5	40
Run and maintain, years two to five	10	20
Total	100	60

Three things to notice, because they are where evaluations go wrong. The custom work line is the one vendor spreadsheets leave out, and it is the line the requirements decide. The internal time line has to be fully loaded on both sides, since a package still needs internal analysts and a build still needs someone to run it. And the years after go-live are where a build pays for its freedom: custom code has to be maintained by someone, and that cost belongs in the model at decision time, not discovered in year three.

How I would phase it, and why

Not as one cutover. The seven functions do not depend on each other equally, and the dependencies set the order.

FirstInventory and procurement, because everything else reads stock
SecondProduction planning, bills of materials, order tracking and sales, because they read inventory and write to it
ThirdFinance, the ledger, and the integration with HR and payroll, because they read everything

Phasing this way means finance is not waiting on inventory for a year for no reason, and each department gets its training and its hypercare while the team still remembers why things were built the way they were. It also means the module with the most edge cases lands last, when the team is strongest, which brings me to the module I would not build at all.

The one module I would buy

I would not build the general ledger.

The whole answer, in one sentence

The operational modules are the right things to build. Inventory, production planning, procurement, the payroll integration: that is where a manufacturer's way of working differs from everyone else's, and no package follows it without being rewritten. A double-entry ledger is not like that. Multi-currency journals, statutory audit requirements, tax filing, rounding rules: commercial ledgers solved those years ago, and every reconciliation edge case a team meets while rebuilding them has been met before.

The better shape is a hybrid. Build the operational core, and post into an established accounting engine through its API for the ledger, statutory reporting and tax. It costs a licence and an integration, and it buys back the months and the audit friction that a homegrown ledger spends. It is not a coincidence that the worked example on this site is a ledger reconciliation. That is the part of any build that teaches the most, mostly by going wrong in small, expensive ways.

How I would run the evaluation

Weight the criteria before the demos, and write the weights down

It is the only defence against a very good presentation.
Make the customization penalty a number, not an adjective

"Needs some configuration" and "40 percent of the logic is custom" can describe the same product. Only one of them can be put in a cost model.
Price the exit

What does it cost to leave each option in year four? Licences end. Custom code has to be maintained by someone. Neither is free, and only one of them shows up in the vendor's spreadsheet.
Split the decision by module

Build or buy is not one question. It is seven, and the answer for a manufacturer is usually build the operational core and buy the ledger. I would ask it that way from the start.

Written by Nasmaan Ibrahim for nasmaan.com. The company and the numbers on this page are illustrative.
Back to the record · One requirement, written out in full · Seventy-six conversations, one page