Artifact §04 · Decision write-up

Build or buy, written up

The ERP at the manufacturer I worked for was built in house. For a consumer goods manufacturer of that size the default is to buy something off the shelf, and "why didn't you?" is the question I still get asked in interviews. This is the answer: what the decision turned on, how I would structure the evaluation now, and the one module I would buy rather than build.

The decision is real and I led the evaluation. The company's figures stayed with the company, so this page does not quote them, and where I show numbers they are illustrative and say so. Like the three pieces before it, nothing here is drawn from an employer's records. The reasoning is mine, and where it differs from what a vendor deck would tell you, that is the point.

The situation

Company: Consumer goods manufacturer in South Asia. Seven business functions, each on its own system or spreadsheet.
Functions: Inventory, production planning, order tracking, sales, procurement, HR, finance
Already built: An in house payroll system, delivered two years earlier: salary processing, attendance, deductions, and tax compliance. I had gathered its requirements and run its acceptance testing.
Requirements: One specification set across all seven functions, with competing needs reconciled before the build started. Where two functions defined the same thing differently, the definition was settled in writing before anything was built.
My role: Ran delivery and owned the requirements across all seven functions, including this evaluation. Delivery team of twelve.
Decided: Build.
Outcome: Delivered through SIT and UAT to business sign-off and cutover. Still in daily use as of 2026.

What the decision turned on

I started from what each of the seven functions actually needed, not from what a vendor demo covered. 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 showed where the factory's way of working was ordinary and where it was not, and the parts that were not ordinary were the parts a package would have needed custom work to follow.

Once that custom work was priced as a number rather than described as an adjective, buying stopped looking like the safe option. It did not remove the software risk or the timeline risk; it put a licence bill on top of both. The numbers said build, and the system that resulted followed the factory instead of the other way round, on a roadmap we controlled, integrated natively with the payroll system we already had.

The options any 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 customisation, at partner rates, and the licence is billed every year in a foreign currency.
A modular, open core ERP

Quicker to stand up and cheaper to enter, with the customisation 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 the national tax and VAT rules

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

The in house engineering team existed, had delivered payroll, and knew the business. The question was whether that was enough, and the honest answer was: for some modules, yes, and for one, no.

Four criteria, weighted before anyone sees a demo

This is how I would weight the decision now, 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 actually works	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 the local currency. 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 company's real figures are not reproduced here. The shape is what matters: a package moves cost into licences and partner customisation, 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 again

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

It is the only defence against a very good presentation.
Make the customisation 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 honest 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 decision is real; the company is not named and its figures are not reproduced. Numbers on this page are illustrative and labelled as such.
Back to the record · One requirement, written out in full · Seventy six conversations, one page · Resume, PDF