A client came to us with what sounded like a straightforward request:
“We need a custom ERP.”
They had already reached the conclusion. They weren't asking whether they should build one. They wanted to know how we would build it.
And, technically, we could have.
Inventory, purchasing, sales, approvals, accounting workflows, reporting, user roles, dashboards, integrations — none of these are impossible engineering problems.
But after digging into the requirements, we recommended something that probably wasn't expected from a software development team:
Don't build the custom ERP.
Not yet, anyway.
The interesting part wasn't that custom software would have been expensive. Everyone already knows that.
The interesting part was that most of the complexity the client wanted us to build wasn't actually unique to their business.
That distinction changed the entire project.
The Request Sounded Like a Custom Software Problem
The initial requirements looked exactly like the kind of list that can push a team toward custom development:
- centralized inventory
- purchase and sales workflows
- role-based approvals
- customer and supplier records
- accounting integration
- reporting dashboards
- document management
- notifications
- different access levels
- integrations with existing systems
Put those requirements into a specification document and you can quickly end up with dozens of modules, hundreds of screens, complex permissions, background jobs, APIs, reports, and business rules.
At that point, building a custom ERP can feel completely reasonable.
But we started asking a different question:
Which of these requirements are actually unique?
That question turned out to be much more useful than asking what technology stack we should use.
“We Have a Unique Process” Is Not the Same as “We Need Unique Software”
Almost every organization has processes that feel unique internally.
Maybe purchase requests move through three people instead of two.
Maybe inventory is transferred between locations in a particular sequence.
Maybe a sales order requires an additional approval above a certain value.
Maybe management wants reports organized differently.
Those things matter.
But they don't automatically justify rebuilding an ERP from zero.
There is an important difference between:
a unique business
and
a unique software requirement.
A company may have spent years developing its operating model, but a large percentage of the underlying software requirements can still be standard.
Customers are still customers.
Products are still products.
Invoices still need line items.
Inventory still moves between locations.
Users still need roles and permissions.
Purchase orders still have statuses.
Transactions still need audit trails.
The terminology and workflow may differ, but the underlying data structures are often surprisingly familiar.
That was the first reason we challenged the original plan.
The Iceberg Under a Custom ERP
The visible part of an ERP is relatively easy to understand.
You see forms, tables, dashboards, search, reports, buttons, and workflows.
The difficult part is everything underneath them.
Consider a seemingly simple purchase order.
Purchase Request
↓
Manager Approval
↓
Purchase Order
↓
Supplier Confirmation
↓
Goods Received
↓
Inventory Updated
↓
Invoice Matching
↓
Accounting
Now add exceptions.
What happens if only half the order arrives?
What if the supplier changes the price?
What if the order is cancelled after partial delivery?
What if the user doesn't have permission to approve that amount?
What if inventory has already been reserved?
What if the invoice and purchase order don't match?
What needs to be recorded for an audit?
What happens when somebody edits the transaction six months later?
The UI is rarely the hardest part.
Business state is.
And an ERP contains a lot of business state.
Building Version 1 Is Only the Beginning
This was probably the biggest part of our recommendation.
When teams estimate custom software, they naturally focus on development.
But an ERP isn't really a project that ends at deployment.
Once you own the system, you also own its evolution.
That means maintaining:
- application code
- database migrations
- APIs
- authentication
- authorization
- audit logging
- integrations
- reporting
- backups
- monitoring
- infrastructure
- security patches
- dependency upgrades
- performance
- documentation
- testing
- user support
Then the business changes.
A new warehouse appears.
An approval rule changes.
A supplier integration is replaced.
Finance wants a new report.
Operations introduces another workflow.
Management wants data that nobody thought to store six months ago.
The software has to change with all of it.
That is why the real question isn't:
Can we build this ERP?
It is:
Do we want to own this ERP as a software product for the next several years?
Those are very different questions.
We Split the Requirements Into Three Buckets
Instead of immediately estimating development, we classified the requirements.
1. Commodity requirements
These were capabilities that established ERP platforms already handle reasonably well.
Examples:
- users and permissions
- customers
- vendors
- products
- inventory
- purchasing
- sales
- invoices
- basic accounting
- standard reports
Building these ourselves would have meant spending engineering time recreating solved problems.
2. Configurable requirements
These were requirements that sounded custom initially but could be handled through configuration.
Things such as:
- approval rules
- user roles
- document sequences
- notification rules
- report layouts
- workflow states
Configuration isn't always effortless, but it is very different from owning an entirely new implementation.
3. Truly differentiated requirements
Finally, we found the smaller set that actually deserved engineering attention.
These were workflows and integrations connected specifically to how the business operated.
And this led to the architecture that made much more sense:
┌───────────────────────────────┐
│ Existing ERP Core │
│ │
│ Accounting │
│ Inventory │
│ Purchasing │
│ Sales │
│ Users / Permissions │
└───────────────┬───────────────┘
│
Custom Extensions
│
┌───────────────▼───────────────┐
│ Unique Business Workflows │
│ Custom Integrations │
│ Specialized Automation │
│ Business-Specific Reporting │
└───────────────────────────────┘
Instead of:
Build everything.
The strategy became:
Use proven software for the standard parts and engineer the parts where customization actually creates value.
Custom Software Wasn't the Problem
This is an important distinction.
We weren't arguing against custom development.
There are plenty of situations where custom software development is exactly the right engineering decision.
If a company's workflow is genuinely proprietary, if existing products create severe constraints, or if software itself creates the company's competitive advantage, owning the system can make sense.
But customization should have a reason.
Building software simply because we can build it isn't a technical strategy.
Sometimes engineering maturity means writing code.
Sometimes it means deciding that a few hundred thousand lines of code shouldn't exist.
Why an Existing ERP Changed the Conversation
Once we stopped treating the problem as “build versus don't build,” another option became obvious.
Use an established ERP as the foundation and customize the smaller portion that actually differs.
Platforms such as Odoo are interesting in this context because the standard ERP foundation can coexist with custom modules, integrations, workflows, reports, and automation.
In other words, adopting an ERP doesn't necessarily mean accepting every default workflow.
There is a middle ground:
Standard ERP
+
Configuration
+
Custom Modules
+
Integrations
=
Business-Specific ERP Environment
That is fundamentally different from starting with an empty repository and rebuilding accounting, inventory, purchasing, sales, access control, reporting, and everything around them.
For teams considering this route, understanding what can be handled through Odoo development and custom ERP workflows is useful before deciding that the entire platform needs to be built from scratch.
The 80/20 Question
We eventually started thinking about the problem using a simple mental model.
Suppose roughly 80% of the required functionality is standard ERP behavior and 20% is genuinely specific to the organization.
A full custom build effectively says:
Let's build 100% so we can control the 20%.
A platform-plus-customization strategy says:
Let's reuse the 80% and concentrate engineering effort on the 20%.
The percentages won't literally be 80/20 for every project.
That's not the point.
The useful question is:
How much of the requested system is actually differentiated?
If the answer is “almost everything,” custom ERP deserves serious consideration.
If the answer is “a few important workflows,” extending an existing platform may be the better engineering decision.
A Better Build-vs-Buy Framework
After going through this process, these are the questions I'd want answered before approving a custom ERP project.
1. Is the process genuinely unique?
Not:
“Do we perform it differently?”
Ask:
“Would changing this process remove a competitive advantage?”
Those aren't equivalent.
2. Can an existing platform cover the boring 80%?
“Boring” is good here.
Authentication should be boring.
Basic inventory should be boring.
Standard accounting workflows should be boring.
Permissions should be boring.
The more solved infrastructure you can safely avoid rebuilding, the more engineering capacity you have for problems that actually differentiate the business.
3. How much customization would the platform require?
There is a point where excessive customization becomes its own problem.
If you have to fight the platform constantly, custom development starts becoming more attractive.
This is why the decision isn't automatically “buy.”
It is:
Buy
↓
Configure
↓
Extend
↓
Build Custom
Move down that list only when the previous option can no longer satisfy the requirements cleanly.
4. What is the five-year cost?
Comparing:
ERP subscription
vs.
development estimate
is incomplete.
A better comparison includes:
Custom ERP
Initial development
+ infrastructure
+ maintenance
+ security
+ upgrades
+ integration changes
+ QA
+ support
+ documentation
+ future development
versus:
Existing ERP
Licensing
+ implementation
+ configuration
+ custom modules
+ integrations
+ migration
+ training
+ support
+ upgrades
Neither side is automatically cheaper.
But at least you're comparing systems rather than invoices.
5. Who owns the system after launch?
This question doesn't get enough attention.
Imagine the original development team is gone three years from now.
Can another engineer understand the system?
Are business rules documented?
Are there automated tests?
Can the system be deployed reliably?
Are integrations documented?
Does anyone understand why important architecture decisions were made?
Custom software creates ownership.
Ownership creates responsibility.
There Is Also a Cost to Over-Customizing an Existing ERP
The opposite mistake is worth mentioning.
You can choose an established ERP and then customize it so heavily that you've effectively created a custom ERP inside somebody else's platform.
That can produce the worst of both worlds.
You still have platform constraints, but now upgrades become difficult because dozens of custom modules depend on internal behavior.
So our rule isn't:
Never customize ERP.
It's closer to:
Customize where the business is different. Configure where it isn't.
That boundary matters.
When I Would Recommend a Custom ERP
There are situations where I'd be comfortable moving in the opposite direction.
A custom ERP becomes much easier to justify when several of these are true:
- core workflows are genuinely proprietary
- those workflows create competitive advantage
- existing platforms require extreme customization
- integrations are unusually complex
- the organization needs deep control over its data model
- platform limitations would constrain future products or operations
- the company has the budget for long-term maintenance
- there is internal technical ownership after launch
The last point is especially important.
A custom ERP shouldn't be treated like a website that gets built, deployed, and occasionally updated.
It is operational infrastructure.
If purchasing, inventory, finance, fulfillment, and reporting depend on it, the company is effectively operating an internal software product.
The Most Valuable Code Was the Code We Didn't Write
Software developers naturally think in terms of building.
Give us a workflow and we start thinking about schemas.
Give us an integration and we're thinking about APIs.
Give us an ERP and we're thinking about services, queues, permissions, caching, event flows, and deployment.
But architecture is partly about deciding what not to build.
In this case, the client's actual problem wasn't:
“We don't own an ERP.”
The problem was closer to:
“Our systems don't match how our operations work.”
Those statements sound similar.
They aren't.
One automatically points toward custom software.
The other leaves several possible solutions open.
That difference can represent months of engineering.
A Simple Test Before You Build
If you're considering a custom ERP, try this before opening your IDE.
Create a table with four columns:
| Requirement | Standard | Configurable | Truly Custom |
|---|---|---|---|
| Inventory | ✓ | ||
| Purchasing | ✓ | ||
| Approval flow | ✓ | ||
| Specialized workflow | ✓ | ||
| Custom integration | ✓ | ||
| User permissions | ✓ | ||
| Custom report | ✓ |
Do this for every major requirement.
Then look at the final column.
That column — not the entire requirements document — is where the real custom ERP discussion should begin.
If almost everything lands there, build may be justified.
If only a small portion does, think very carefully before rebuilding the rest.
Final Thought
Talking a client out of building software might sound strange for a software development team.
But “we can build it” and “you should build it” are completely different conclusions.
A custom ERP can be a powerful investment when the software needs to encode something genuinely unique about a business.
It can also become an expensive way of rebuilding functionality that mature platforms have spent years solving.
The goal shouldn't be maximum customization.
It shouldn't be minimum code either.
The goal is to put custom engineering exactly where it creates an advantage — and use proven systems everywhere else.
Sometimes the best architecture starts with choosing the right technologies.
And sometimes it starts with deciding what you're willing not to build.
