Should your ERP partner build it?

If your organization runs an ERP, somebody implemented it, and that firm is almost certainly still reachable. Before commissioning custom software from anyone, us included, ask them whether they will build the thing you need. It is the cheapest question available and a surprising number of buyers skip it, usually because the last conversation with that partner was about a renewal rather than a build.

We recommend this against our own immediate interest, for a straightforward reason: if the work belongs inside the ERP, having it built there is better for you than anything we would do instead. Fewer systems, one support relationship, no integration to maintain. We would rather be the second call on work that genuinely needs us than the first call on work that did not.

What the answer usually is, and why¶

ERP partners build inside the platform. That is the whole shape of the practice, certified consultants, platform-specific tooling, an upgrade path they are responsible for, and an economic model built around the vendor's release cycle. Inside that boundary they are genuinely good and hard to beat on price.

The work they tend to decline is the work that leaves the platform. In our experience that clusters tightly, and it is worth knowing the pattern before you ask, so you can read the answer accurately:

• Anything on the plant floor, machine data, line state, anything with a controller behind it.
• Anything in the yard, on a truck, or with a field crew, where connectivity is intermittent and the interface has to work on a phone in a glove.
• Anything talking to a device or an instrument, where the protocol is the problem rather than the business logic.
• Anything with a hard real-time or high-frequency requirement, where the constraint is latency rather than throughput.
• Anything needing an interface for people who do not have an ERP licence and never will, customers, subcontractors, inspectors, drivers.

How to read the answer you get¶

You will rarely get a flat no, because flat noes lose accounts. The useful signal is in the shape of the response rather than its wording.

Any of these is worth having in writing before you brief another firm, because it defines the boundary. The most common way this decision goes wrong is not choosing the wrong builder; it is nobody ever establishing where the ERP's responsibility stops, so two systems end up holding the same record and disagreeing.

If the answer is no¶

Then you are looking for somebody to build the part that sits outside, and the single most important property of that work is how it relates to the ERP. It should integrate rather than duplicate. The ERP stays the system of record for whatever it already owns (customers, parts, orders, financials) and the new system references those records rather than keeping its own copy that drifts.

That is a design constraint worth stating in the brief, because the alternative is easy to build and painful to live with. A system that maintains its own customer list because integration looked expensive has not avoided the cost; it has converted it into a reconciliation problem that somebody performs by hand every month, forever.

Nothing here is an argument about your ERP. That decision was made for reasons that were probably sound, it is expensive to revisit, and it is not the question in front of you. The question is only which work belongs inside it, and the firm that implemented it is genuinely the best-placed party to answer that first.