Custom production software vs off-the-shelf MRP: which is right?
We build bespoke production systems, so treat what follows with appropriate suspicion. But we also tell manufacturers to buy off-the-shelf when it fits, because a custom build that duplicates a product you could have licensed is a bad outcome for everyone. Here is how the decision genuinely breaks down.
Start with the fit test
Take your five most common production scenarios and walk each one through the MRP package you are considering, using its standard workflow. Not the sales demo — your actual jobs. Count how many require a workaround: a field used for something other than its label, a stage tracked in a spreadsheet alongside the system, a step someone has to remember because the software cannot represent it.
Where off-the-shelf MRP wins
- Your process is close to standard — discrete manufacturing, conventional stages, nothing unusual.
- You need it running in weeks rather than months.
- You want a vendor with a support desk and a published roadmap.
- Compliance modules you would otherwise have to build exist already.
- Budget is tight and predictable licensing suits you better than a capital project.
Where custom wins
- Your process genuinely differs from the norm — unusual routing, mixed-mode production, a stage the packages do not model.
- You are already running several spreadsheets alongside an MRP to cover its gaps.
- Per-seat licensing has become expensive as headcount grew, particularly if you want shop-floor operators to have access.
- You need specific traceability that the package handles awkwardly.
- The shop floor needs a genuinely different interface to the office, which most packages do badly.
The hidden cost nobody quotes
MRP implementations fail more often on process change than on software. If the package requires your floor to work differently, you are paying for the licence plus the retraining plus the productivity dip while people adjust — and the informal knowledge that made the old way work often does not survive the transition. That cost rarely appears in the comparison spreadsheet, and it is frequently larger than the licence.
The hidden cost of custom
In fairness, the other side has one too. Custom software needs someone to maintain it. If you build a system and the developer disappears, you own code nobody understands. Ask about handover, documentation and code ownership before signing anything — and be wary of a build you cannot take to another developer.
The middle path most people miss
You do not have to choose one system for everything. A common and sensible arrangement is off-the-shelf for finance and stock, where the requirements are genuinely standard, plus a custom layer for shop-floor tracking, where your process is specific. The two integrate. This is usually cheaper than either extreme and it is under-considered because vendors on both sides have an interest in selling you the whole thing.
Questions to ask a custom developer
- Can I see something similar you have already built, working?
- Do I own the code, and can another developer maintain it?
- Is the quote fixed, and what happens when scope changes?
- What does handover include — documentation, deployment guide, training?
- What happens if we stop working together?
If the answers are vague, that tells you more than any feature list. One more worth asking: is this a product you configure for me, or something built around my process? A developer selling you a reskinned template is offering the same rigidity as the MRP you were trying to escape, at a worse price. Ours are on our production systems page, and there is a sample system you can click through without talking to anyone first.