Custom ERP: operations that standard software cannot model
Stock, purchasing, production, and traceability designed for how you move goods and money — without modules that no one configures.
The problem
A generic ERP forces you to adapt your operations to the software: warehouse locations that do not exist, production orders that do not reflect your phases, or reports that require an external consultant to generate.
Many SMEs operate with Holded for invoicing, Excel for stock, and WhatsApp for urgent warehouse issues. The cost is not just lost time: it includes stockouts, duplicate purchases, and customers waiting without knowing the real status.
Building a custom ERP does not mean replicating SAP. It means covering critical operational processes with reliable data, clear permissions, and visibility for those making purchasing, pricing, or production decisions.
If this sounds familiar, you are not alone: most SMEs reach the same point before considering building. The question is not 'Can we afford custom software?' but 'How much does it cost to continue as we are for another year?'. That cost — hours, errors, lost opportunities — is often greater than that of a well-defined initial milestone.
In operations, a minute's delay in seeing available stock can mean a confirmed order without materials. Custom ERPs prioritise operational truth in a timely manner, not a thousand reports that no one opens.
In practice, ROI is measured in weeks: hours saved from copying data, errors that no longer occur, and decisions made with same-day information. If you cannot estimate that savings, it is worth doing so before requesting a quote — we help with diagnostics to provide conservative numbers.
If you have made it this far, you have probably already discussed internally that 'we need a system'. The next step is not to request three generic quotes: it is to write a paragraph about what the system should do on the Monday it goes into production and who will validate it. That defines the MVP better than any list of features copied from a competitor.
What is a custom ERP
It is software for managing resources and operations: inventory, purchasing, suppliers, production, shipments, and, if applicable, invoicing or accounting integration.
It is modelled according to your warehouses, units of measure, replenishment rules, BOMs, or approval flows. What would be 'impossible configuration' in a standard ERP is a first-class requirement here.
It usually integrates with CRM, ecommerce, carriers, and accounting so that operations do not exist in silos.
At RUMAZA, we approach it with verifiable deliverables: something in production that the team uses, adoption metrics, and a roadmap for later phases only if the previous phase delivers measurable value. No infinite roadmap or paying for fluff.
Do not confuse custom ERP with cloning SAP. Many projects start with inventory + orders + purchasing and leave accounting in the system you are already using, well integrated.
Operations stop putting out fires when stock and orders reside in one place with clear reservation and shipping rules.
The traceability required by some clients or regulations (batch, expiry, origin) is not an optional module at the end: it is designed into the data model from day one or the subsequent migration is painful.
When it makes sense
- You manage stock across multiple warehouses or with complex rules
- Production or assembly requires specific traceability
- Odoo or another ERP forces you to have permanent consultants
- You need to unify operations with a B2B portal or your own ecommerce
- Operational reports are critical and the current ones are inadequate
- You want to avoid licensing by module that you do not use
- Management requests visibility and data takes days to be ready
- An error in the current process has a direct impact on customer or margin
- You have tried patches (macros, Zapier, templates) and they can no longer handle volume
- You want to document the decision criteria before investing — this custom ERP guide helps you compare options
- You are looking for a partner who speaks in deliverables and not in indefinite hours of 'analysis'
- You want to compare build vs buy with numbers before signing
What can be built
Inventory management
Entries, exits, transfers, cyclic inventories, and minimum alerts. Designed for real adoption: simple screens, validated data, and fewer fields than a generic SaaS.
Purchasing and suppliers
Requests, purchase orders, receipts, and price history. Designed for real adoption: simple screens, validated data, and fewer fields than a generic SaaS.
Production / assembly
Manufacturing orders, material consumption, and estimated costs. Designed for real adoption: simple screens, validated data, and fewer fields than a generic SaaS.
Shipping and logistics
Order preparation, integration with carriers, and tracking. Designed for real adoption: simple screens, validated data, and fewer fields than a generic SaaS.
Operations dashboard
KPIs for turnover, stock value, pending orders, and bottlenecks. Designed for real adoption: simple screens, validated data, and fewer fields than a generic SaaS.
Subsequent evolutionary phase
Expansion of the initial module with new integrations, roles, or reporting — only after validating adoption and ROI from the previous phase. Avoid building functions that no one requested in the urgency of day one.
How RUMAZA would build it
Possible technologies
- Django
- PostgreSQL
- Celery
- REST APIs
- Next.js
- EDI/CSV integration
- Barcodes
Hypothetical application scenarios
Stock, purchasing, or production in separate sheets
Duplicated references, outdated stock, and no one trusts the number. Lightweight ERP focused on operations, not on hundreds of empty modules.
Oversized ERP for the SME
High licensing and consulting costs for functions you do not use. Custom in core operations; SaaS in accounting if it fits.
Traceability by batch, work, or project
Need to track materials, costs, or phases with specific rules. A system that reflects how you work, not a generic template.
Common mistakes
- Wanting to digitise the entire company in phase 1
- Not involving the warehouse in screen design
- Underestimating the migration of references and initial stock
- Ignoring label printing or reading hardware
- Not defining what happens when there is a discrepancy in inventory
- Postponing the decision another year 'until we grow a bit more' — chaos also scales
- Not measuring before/after: without a baseline you do not know if the project worked
- Requesting a quote without defining MVP or a person to validate deliverables on behalf of the business
Frequently asked questions
Custom ERP or Odoo?
Odoo if you fit into its modules and have a trusted partner. Custom when operations are the differentiator and adaptations outweigh the benefits of the standard.
Does it replace accounting?
Not necessarily. Many projects integrate with Holded, Sage, or similar, and the ERP covers operations.
How long does it take?
A stock + orders module usually takes 8–14 weeks. Broader projects are done in phases.
Does it work offline in the warehouse?
We can design resilient mobile flows; complete offline depends on requirements and synchronization conflicts.
Can I start only with inventory?
Yes. It is an excellent first milestone with measurable ROI.
How do I know if we are ready to take the step?
If you can name a specific process that hurts every week, there is an internal owner willing to validate, and the cost of the status quo is greater than €5,000–10,000 annually in time or errors, it deserves a diagnostic conversation. If not, sometimes it is enough to organise data and make better use of what you already have.
How do I prepare the initial inventory?
Physical inventory on an agreed date, unified references, and defined location rules. We help with loading templates and reconciliation against Excel or the previous system.
What specific deliverables do I receive at each phase?
At each milestone: code in your repository, staging environment to test, deployment and usage documentation, and acceptance criteria signed before going into production. We do not deliver just a ZIP or an 80-page PDF that no one reads. The deliverable must be usable by someone other than the developer.
Do you work with internal teams or only externally?
Both. If you have a technical person, we integrate into your flow (Git, tickets, reviews). If not, we take over the entire operation but leave documentation so you are not held hostage. We recommend at least one business representative to validate each sprint.
What happens if our process changes in six months?
A custom system should evolve with you. That is why we avoid shortcuts that prevent changing rules: readable code, documentation, and improvement phases. Small changes go to maintenance; model changes are budgeted as a new phase with clear impact.
How are permissions and security managed?
Roles defined from the MVP: who sees, who edits, who approves. Authentication with email/password or SSO if you already use it. Sensitive data encrypted in transit, automatic backups, and logs of critical actions. It is not paranoia: it is to prevent an intern from exporting the entire customer database unintentionally.
Do you provide training to the team?
Yes, a practical session of 1–2 hours on the delivered flow, plus brief documentation with screenshots. We prefer training on the real MVP, not on 50 functions that will come in phase 2. If support is needed in the first weeks, it is agreed as post-launch support.
What is the first concrete step if I want to move forward?
A message with the process that hurts the most, who suffers from it, and what tools you use today (even if it is Excel). Within 48–72 hours, we respond with a recommendation for the first milestone, order of phases, and an indicative estimate — without commitment to a closed project if it does not fit.
Related guides
Do you have this problem in your company?
Tell me and I will tell you what system I would build.