Search this comparison and almost every result is written by an implementation partner for one of the options. That is not dishonesty exactly — it is that nobody writes a comparison of things they do not sell.
We build custom platforms. We also tell roughly one in six discovery clients that a packaged product would serve them better, and this article is the reasoning behind that.
The axis that matters
Not features. Every one of these can raise a purchase order and post to a ledger. The axis is who controls the timing of your next change.
- With a packaged product, your changes live inside someone else's release cycle.
- With a custom build, you control the cycle and carry the cost of maintaining it.
Everything below follows from that.
What each one actually is
ERPNext
Fully open source, with no paid edition gating core modules. Manufacturing, stock, accounting, HR and CRM are all present, and Indian GST handling is mature because a large part of the community is Indian.
Extensible through its own framework, which means real customisation is possible — and also means your customisations are coupled to that framework's upgrade path.
Odoo
Split between Community and Enterprise, so some functionality sits behind a subscription. The larger partner network and app marketplace are genuine advantages: for most standard requirements, someone has already built the module.
The trade is the same as ERPNext's plus a commercial edge — the boundary between free and paid can move, and modules you depend on may sit on the wrong side of it.
A custom build
Exactly your process, no licence per seat, and the upgrade cycle is yours. In exchange you own maintenance, and you have to be able to articulate the process well enough to build it — which is harder than it sounds and is where most of the cost sits.
The upgrade cliff, which decides more than anything
Configuration survives upgrades. Customisation does not.
When you modify a packaged product beyond its configuration surface, every significant vendor release puts those modifications back on the table to be re-tested, re-fitted or abandoned. Organisations meet this in year three, when a compliance-driven upgrade turns out to be blocked by the customisations that made the product usable in year one.
This is the mechanism behind the whole decision. A product used as designed is cheap forever. A product bent significantly out of shape is expensive twice — once to bend it, and again at every release.
The fit-gap test
Not a feature matrix. A count.
- List the steps in your core processes as actually performed, including the exception paths.
- For each, mark whether the product handles it by configuration, by customisation, or not at all.
- Count only the second and third columns.
A short list means buy the product. A long one, concentrated in the processes that make you money, means the product will be bent until it breaks — and you will pay for that bending at every upgrade.
The discipline is in step one. A fit-gap run against the process as described rather than as performed will always look favourable, because the described process is the one the product was designed for.
Where each wins
| Situation | Answer |
|---|---|
| Standard operations, cost-sensitive, small IT function | ERPNext or Odoo |
| Need a specific vertical module that already exists | Odoo, if the module is maintained |
| Want open source with no paid gating | ERPNext |
| The differentiating process has no equivalent in any product | Custom |
| Several hundred users and growing | Custom, on per-seat economics alone |
| A packaged ERP was already tried and abandoned | Custom, usually — but find out why first |
| Organisation still changing shape fast | Packaged, until it settles |
The hybrid nobody prices
Build and buy are not the only options. A common and underused answer is packaged core, custom edge: run ERPNext or Odoo for finance, stock and procurement where your process is ordinary, and build the differentiating layer — the configurator, the plant integration, the dealer portal — as its own system, integrated.
It works where the boundary between ordinary and differentiating is clean. It fails where the differentiator is buried inside a core process, because then you are back to bending the product.
The question that settles most cases
Is the unusual thing about your process a differentiator, or an accident of history?
Organisations routinely defend a process on the grounds that it is theirs, when it is the residue of a decision made in 2011 by someone who has left. Building around an accident encodes it for another decade at considerable expense.
If it is genuinely why you win, build it. If it is history, fix the process and buy the product — and the fit-gap will look completely different once you have.