Running operations on software that matches how you operate
An ERP runs operations: inventory, purchasing, production, fulfilment and the financial record behind them. Custom is justified when your operational model is genuinely unusual. Most businesses are better served configuring Odoo, Zoho or a comparable platform.
ERP is where custom software projects get most ambitious and most dangerous. The scope touches every department, the data is the company's operational record, and the failure mode is not a disappointing product but a business that cannot ship, invoice or count stock. This is the category where 'start small' matters most and is hardest to do.
ERP projects fail through scope assembled from every department at once. Each function contributes requirements, nobody can decline any of them, and the result is a two-year programme delivering nothing until it delivers everything. The second failure is data: the existing operational record is inconsistent in ways nobody has confronted, and the migration surfaces years of accumulated compromise at the worst possible moment.
When this work makes sense
Questions worth asking any supplier
Has Odoo or a comparable platform been genuinely evaluated against your process?
Which single function hurts most? That is where a staged build starts.
What condition is your operational data actually in? This determines most of the migration cost.
Can you run old and new in parallel during transition? A hard cutover on operational systems is severe.
Who owns this internally? ERP without an internal owner does not survive contact with departments.
Deliverables
Build-versus-configure assessment against the platforms that might fit
A staged plan delivering one function at a time, in production, before the next
Core data model for products, stock, locations, suppliers and transactions
The modules agreed, built and deployed in priority order
Integration with accounting, and with the systems remaining in place
Data migration with reconciliation against the existing record
Role-based permissions across departments
Parallel running period where the old system remains available
Built with
Process
We deliver one operational function at a time into production, and the first is chosen as the one causing most pain rather than the one that is architecturally tidiest. Each function must be working and adopted before the next begins. It produces a longer overall timeline and a shorter time to first value, and it is the only approach we have seen survive an ERP project's inevitable scope pressure.
The standard nine stages, discovery, strategy, UX/UI, development, content and SEO, testing, launch, measurement and continuous improvement, apply to every project. The paragraph above is what differs for this one.
What moves the number
Pricing depends on scope, functionality, integrations and content requirements. These are the factors that change it most:
Platform ERP, configured platform, or custom
Off-the-shelf ERP
Fits: Businesses whose operations resemble the standard model
Limits: You adapt operations to the software, which is disruptive but often correct
Configured platform (Odoo and similar)
Fits: Mostly standard operations with specific requirements
Limits: Heavy configuration becomes its own maintenance burden without code's benefits
Custom build
Fits: Genuinely unusual operations where the process is a competitive advantage
Limits: Highest cost and risk; touches every department
Case studies
No published ERP case study. Operational systems are commercially sensitive to the businesses running them.
MBGDesk operates from 4 offices in India, United States, United Kingdom, United Arab Emirates. We hold no industry certifications and do not imply otherwise.
Frequently asked questions
Should we build an ERP or configure one?
Configure, unless your operations are genuinely unusual in a way that matters commercially. ERP platforms encode decades of operational patterns. Rebuilding that to accommodate a process that evolved by accident is the most expensive mistake available in this category.
How long does an ERP project take?
Longer than anyone wants, which is why we stage it. A single function in production within a few months is achievable. A complete replacement of everything is a multi-year programme and those are the ones that fail.
What happens to our existing data?
It gets migrated and reconciled, and the migration usually reveals inconsistencies nobody had confronted. Stock counts that never matched, duplicate supplier records, historical entries in formats that changed. Confronting that is part of the project rather than a surprise within it.
Can we run the old system in parallel?
Strongly recommended for anything operational. A hard cutover on the system that runs shipping and invoicing leaves no fallback, and the cost of a parallel period is small against the cost of a week unable to dispatch.
Which function should we build first?
The one causing most pain, not the one that is easiest or most architecturally satisfying. Early delivery has to demonstrate value to the people who will have to change how they work, or the project loses support before the second phase.
What about Odoo?
A genuinely good option for many businesses and we will recommend it where it fits. It covers a wide operational range at a fraction of a custom build. The caution is that very heavy customisation of Odoo becomes its own maintenance burden while remaining constrained by the platform.
How do we stop scope expanding?
Staged delivery with each phase in production before the next starts. Scope expands when nothing has shipped, because there is no cost to adding requirements to something that does not yet exist. Working software is the best discipline available.
Services that connect to this
Talk to us about this
Tell us what you are trying to build and we will come back with scope, approach and an estimate.