Custom ERP versus a packaged suite like SAP
Neither answer is universal. The decision turns on how much of your process is genuinely unusual, and how much change you can absorb.
Custom build
Software shaped to your process
Packaged suite
Your process shaped to the software
We build custom ERP, so read this knowing where we sit. We also turn this work down regularly, because for a large number of companies a packaged suite is straightforwardly the better decision and saying otherwise would cost you money.
The question is not which is better. It is how much of your operation is genuinely unusual, and how much process change your organisation can actually absorb. Get those two answers and the decision mostly makes itself.
Where they actually differ.
| Dimension | Custom build | Packaged suite |
|---|---|---|
| Time to first value | 8–16 weeks for a working first module, but the full estate takes considerably longer. | Faster for standard finance. Slower than promised once configuration and data migration are real. |
| Fit to your process | Exact, because the process is the specification. The risk is codifying a bad process. | Good on commodity functions. Anything unusual becomes a workaround with its own upkeep. |
| Five-year cost shape | Higher upfront, no per-seat licence, ongoing maintenance is your own team or retainer. | Lower upfront, then licence plus 18–22% maintenance annually, growing with seats. |
| Changing an approval rule | Configuration change your own team makes, same day. | Often a change request with a consultant rate attached, and a retest at next upgrade. |
| Statutory and tax compliance | You own keeping up with legislation. Real, recurring, and easy to underestimate. | A genuine strength. The vendor tracks tax law across jurisdictions so you do not. |
| Upgrade burden | You upgrade dependencies on your schedule. No forced migrations. | Major upgrades every 3–5 years; a heavily customised instance approaches reimplementation. |
| Hiring and continuity | Standard developers can maintain it. Needs a team, or a retained partner. | Specialist consultants, scarcer and more expensive, but a deep market exists. |
| Audit and diligence | Designed for your auditor's questions. Buyers may see a custom system as key-person risk. | Familiar to auditors and acquirers. Rarely questioned in diligence. |
- Your competitive advantage is in a workflow no packaged product models — yard logic, batch genealogy, a contract pricing engine nobody else has.
- You have already implemented a suite and the workarounds now cost more than the software saves.
- Per-seat licensing at your headcount has become the dominant line item.
- You need a system of engagement for staff, customers or suppliers that the suite simply does not provide.
- You have, or will retain, engineering capacity. Custom software with nobody maintaining it becomes the legacy problem you were escaping.
- Your processes are broadly conventional, and honestly assessed — most companies believe they are unusual and most are not.
- You need statutory and tax compliance across multiple jurisdictions maintained for you. This alone justifies buying for many businesses.
- You have no engineering function and no intention of building one.
- You are preparing for acquisition or investment and want systems a diligence team recognises immediately.
- The requirement is finance, payroll and standard reporting. These are solved products and building them is close to indefensible.
Our view
For most companies the durable answer is neither extreme: a packaged system as the financial system of record, custom software for the differentiating workflow, and a deliberately engineered integration layer between them. The integration is the part that decides whether this works or becomes permanent pain, and it is routinely treated as an afterthought.
Follow-ups.
Do you implement SAP if we decide to buy?
No. We build custom software from scratch and do not write ABAP, configure packaged suites or resell licences. If buying is the right answer we will tell you so and point you at a specialist partner — we would rather lose the work than take on an implementation we are not the right firm for.
Can we start custom and move to a suite later, or the reverse?
The realistic path is the hybrid: keep the ledger in a packaged system and build outward from it. Wholesale migration in either direction is expensive and usually driven by a change of leadership rather than a change in the facts.
How do you model the five-year cost honestly?
By including what vendor comparisons leave out on both sides: implementation at two to four times first-year licence, data migration and cleansing, process change and the productivity dip after cutover, annual maintenance, upgrade projects — and on the custom side, the permanent cost of a maintaining team.
Tell us what you are building.
A short conversation is usually enough to tell whether we are the right firm for the problem. If we are not, we will say so and point you somewhere better.