Custom ERP versus Odoo
The question is not whether Odoo can do it. It is how much you will have to change it, and what that costs you at every version upgrade.
Custom build
No upstream to stay compatible with
Odoo
A large head start, if your process fits
Odoo is a serious product and a reasonable default for a mid-sized business whose processes are close to conventional. It is modular, the module library is large, it can be self-hosted, and it gives you a very substantial head start over an empty repository.
It also has a specific and well-documented failure mode, and it is worth naming because it is the reason most rescue work arrives. The phrase that precedes it is almost always the same: we will just customise it a little. Customisation is easy at first, which is the trap — each change is small, each is justified, and there is no moment at which anyone decides to fork the product. Then a major version arrives, and the accumulated modifications turn what should be an upgrade into a project with a testing burden nobody budgeted.
So the real comparison is not features. It is the distance between your process and Odoo's model, and your honesty about that distance at the start.
Where they actually differ.
| Dimension | Custom build | Odoo |
|---|---|---|
| Starting point | Empty. Everything is built, which is slower initially and carries no assumptions. | Substantial. Accounting, inventory, purchase and sales exist on day one. |
| Fit to an unusual process | Exact, because the process is the specification. | Good where your process resembles the model, increasingly costly as it diverges. |
| How customisation works | You change your own code. There is no upstream to remain compatible with. | Extension modules over core behaviour. Workable until they overlap or core changes underneath. |
| Upgrade burden | You upgrade dependencies on your own schedule. No forced migration. | The decisive factor. Lightly extended upgrades are routine; heavily modified ones approach a rebuild. |
| Deployment | Anywhere you choose, including your own hardware, with no licensing dimension. | Cloud or self-hosted. Self-hosting is genuinely supported, which is a real advantage. |
| Talent | General developers in your stack. Broad hiring pool, no product-specific skill required. | Odoo-specific developers. A real market exists, with wide variation in quality. |
| Cost shape | Build cost upfront, then maintenance. No per-user licensing dimension at any scale. | Lower to start. Cost concentrates in implementation, customisation and each upgrade. |
| Risk profile | Execution risk is yours: scope, pace and whether the team is any good. | Risk sits in the customisation depth, and it is usually discovered at the first major upgrade. |
- Your core operational process is genuinely unlike standard manufacturing, distribution or retail flows — yard logic, batch genealogy, a contract pricing engine, a scheduling problem specific to your industry.
- You have already customised Odoo or a similar suite heavily, and upgrades have become projects you defer.
- The system is a system of engagement for customers, suppliers or field staff, not a back office. Suites are weakest exactly here.
- You need to integrate deeply with physical equipment or a real-time data stream, at volumes a general-purpose ERP was not designed to carry.
- You intend to own engineering capability anyway, in which case the head start matters less than the ceiling.
- Your processes are close to conventional, and you are willing to adapt to the software rather than the reverse. This is the whole decision, and it is usually decided by leadership rather than by software.
- You need a functioning back office soon and across many functions at once. Starting from an empty repository cannot compete on that.
- You want a system you could hand to another partner later. A widely used product has a market of firms who can take it over; bespoke software has whoever you engage.
- Your budget suits a phased implementation better than a build, and you would rather spend on configuration than on engineering.
- You can commit to staying close to standard. If that commitment is real, Odoo is a good answer for a long time.
Our view
The decision rule we would actually apply is about distance and discipline rather than features. If you can keep your modifications to configuration and light extension, Odoo is a strong choice and building would be waste. If you already know that the process you compete on will require reaching into core behaviour, you are choosing to maintain a fork of somebody else's product — and doing that deliberately, with a custom system for the differentiating part and the suite for the conventional back office, is almost always the cheaper version of the same ambition.
Follow-ups.
Do you implement or customise Odoo?
No. We build custom software from scratch and do not implement packaged or open-source suites. If Odoo is the right answer we will tell you and point you to a specialist partner. We would rather lose the work than deliver an implementation we are not the right firm for.
We have a heavily customised Odoo instance we cannot upgrade. What are the options?
Three, honestly. Stay on the current version with a plan for security patching, which is viable for longer than people assume. Reimplement on a current version and deliberately move logic out of core. Or extract the differentiating parts into a separate system and return the suite to something close to standard. The third is often cheapest over five years and is the least often proposed, because it is the one nobody sells.
Is open source cheaper than building?
Usually to start, and the gap narrows with how far you diverge. The cost that gets missed is not licensing — it is the recurring upgrade and regression testing burden that grows with every core modification. Costed over five years with upgrades included, a lightly customised instance is clearly cheaper and a heavily modified one frequently is not.
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.