Why nobody can quote you a price on a phone call
A custom ERP is not one product. It is a set of modules that share one database, and the cost is driven almost entirely by how many of those modules you need and how tightly they have to agree with each other.
Two companies can both ask for an ERP and get quotes that differ by a factor of five, honestly. One needs stock and invoicing. The other needs stock, invoicing, multi-warehouse transfers, payroll for two hundred people, and a general ledger that a chartered accountant will sign off on. The second system is not twice the work. It is closer to ten times, because every module has to reconcile with every other one.
Anyone who quotes a fixed price before asking which departments are involved is either guessing or planning to bill you for the difference later.
Driver one: how many departments the system touches
Each department you add brings its own rules, its own exceptions, and its own reconciliation with the modules already built.
Inventory alone is straightforward. Inventory plus purchasing means every stock movement must trace to a purchase order. Add accounting and every one of those movements must also produce a journal entry that balances. Add payroll and the system now holds personal data, which changes how it must be secured and who may see what.
The practical rule: the cost of module number five is higher than the cost of module number one, because it has to agree with four others.
Driver two: how much history has to come with you
Migration is the most commonly underestimated line in any ERP quote, and it is where projects fail quietly.
Opening balances are the critical path. If your stock quantities, supplier balances and trial balance are wrong on the day you go live, they are wrong forever, because every later figure is calculated from them. Correcting them a month in means unwinding a month of transactions.
This is why a serious vendor will ask for your opening trial balance before writing a single screen. If nobody has asked you for it, that is a signal.
Budget real time for the client-side work too. The data usually has to be cleaned by the people who own it, and that is your team's hours, not the vendor's.
Driver three: what the system has to talk to
Every external integration is a separate small project with its own failure modes.
Payment gateways are the clearest example. Integrating bKash, Nagad or SSLCommerz is not simply calling an API. The work is in the paths nobody demos: what the system does when a payment succeeds at the gateway and the callback never arrives, when a customer pays twice, when a refund is partial, and when the reconciliation report disagrees with your own ledger.
The same is true of attendance devices, courier APIs, and SMS providers. The happy path is a day. The failure paths are the project.
Driver four: compliance
In Bangladesh, VAT compliance changes the shape of a retail or distribution system rather than adding a feature to it.
A VAT-registered business needs invoices that satisfy the NBR's requirements, and a point of sale that can produce them at the counter. That constrains the invoice numbering, what must be stored per line, and what can be edited after the fact. Retrofitting it into a finished system is considerably more expensive than designing for it at the start.
Decide early whether the system must be compliant. It is a design input, not a later feature.
What does not drive the price as much as people expect
The user interface. Screens are visible, so they feel like the product, but a well-built module spends most of its cost on rules and reconciliation rather than on layout.
The number of users. Licensing models make this feel expensive, but in custom software the difference between twenty users and two hundred is mostly infrastructure, which is cheap by comparison.
The number of reports. Once the underlying data is correct and consistent, most reports are inexpensive. If reports are being quoted as a large line item, it usually means the data model underneath is not doing its job.
How to read a quote
Ask what happens when something fails. A vendor who can describe, specifically, what their system does when a payment callback never arrives has built one before.
Ask who owns the code and the database when the project ends. Get the answer in writing.
Ask what is excluded. Data migration, training, and the first month of corrections are the three items most often left out of a low quote and billed later.
Ask to see something running with real-shaped data, not a slide deck. Anyone can demo a feature. The question that decides whether a business can trust a system is what happens on its worst day, not its launch day.
- How much does a custom ERP cost in Bangladesh?
- There is no single figure, because the cost is driven by how many departments the system covers, how much historical data must be migrated, how many external systems it integrates with, and whether it must satisfy VAT compliance. A system covering stock and invoicing is a fraction of the cost of one that also covers multi-warehouse transfers, payroll and a general ledger, because every additional module must reconcile with the ones already built.
- Is custom ERP cheaper than off-the-shelf software?
- Not upfront. Off-the-shelf is almost always cheaper to start. Custom becomes worth it when your process is genuinely different from the software's assumptions, when the licence cost per user grows faster than your margin, or when the off-the-shelf product cannot produce a document your regulator requires.
- What is the most underestimated cost in an ERP project?
- Data migration, and specifically opening balances. If stock quantities, supplier balances and the trial balance are wrong on go-live day, every figure calculated from them is wrong afterwards. Correcting them later means unwinding every transaction posted since. Much of this work also falls on the client's team rather than the vendor's, so it is often missing from both the quote and the plan.
- How long does a custom ERP take to build?
- Time scales with the same drivers as cost. A single-module system is measured in weeks. A multi-department system with payroll and a general ledger is measured in months, and the go-live is gated by data readiness on the client side rather than by development.
- What should I ask a software vendor before signing?
- Ask what the system does when a payment succeeds but the callback never arrives. Ask who owns the code and database at the end of the project, and get it in writing. Ask explicitly whether data migration, training and post-launch corrections are included. Ask to see software running with real-shaped data rather than a presentation.