Custom ERP development cost is the effort needed to design, build, test, migrate and support the specific modules your business needs, multiplied by the rate of the team doing the work. The biggest drivers are scope (modules and workflows), the number of legal entities, integrations, data migration, roles and approvals, languages, hosting and the support model after go-live.
That is why two honest quotes for "an ERP" can differ by a large multiple: they are usually pricing different scopes. This guide does not quote prices. It explains what moves the number, how to estimate it yourself before you talk to a vendor, and why a fixed quote given before any discovery is usually less certain than it looks.
What actually drives the cost of a custom ERP?
Cost follows the amount of distinct behaviour the system must have. Every module, rule, integration and report is work that has to be specified, built, tested and maintained. The table below lists the drivers that matter most, with what makes each one cheap or expensive.
| Driver | Lower effort when | Higher effort when |
|---|---|---|
| Modules | A few core modules (for example finance, inventory, sales) | Many modules with deep cross-dependencies (production, projects, HR, payroll, service) |
| Workflow complexity | Standard document flows with one approval step | Multi-level approvals, exceptions, partial deliveries, returns, back-orders |
| Legal entities | One company, one currency | Several companies, inter-company trading, consolidation, multiple currencies |
| Integrations | One or two systems with documented APIs | Many systems, old systems without APIs, real-time two-way sync |
| Data migration | Clean spreadsheets, active records only | Several legacy sources, poor data quality, years of open transactions |
| Roles and permissions | A handful of roles | Field-level permissions, branch-level data separation, segregation of duties |
| Languages and locales | One language, one tax regime | Bilingual interface (including right-to-left Arabic), several tax regimes |
| Reporting | Standard operational lists | Management packs, consolidation reports, custom dashboards |
| Hosting and environments | One production and one test environment | Several environments, strict data residency, high availability requirements |
| Support after go-live | Business-hours fixes | Extended hours, guaranteed response targets, ongoing feature work |
If your project sits on the right-hand side for most rows, it is a large programme whatever the vendor's daily rate. If you are planning a system built around your own processes, our custom ERP software page explains how we scope it.
The hidden drivers buyers forget
- Decisions inside the business. Each unresolved question (who approves a credit note, how landed cost is split) becomes rework later.
- Testing with real users. User acceptance testing needs your people's time, and their availability sets the pace.
- Reports nobody listed. Finance teams often discover the reports they need during testing, which is the most expensive time to add them.
- Change after sign-off. New requirements are normal; what matters is that they are reviewed and agreed before work starts.
How do you estimate custom ERP cost before talking to vendors?
Break the system into countable pieces, size each piece relatively, and add allowances for the work that is not features. You will not get an exact number, but you will get a defensible range and a much better conversation with vendors.
Step 1: List the modules and rank them
Write down every module you think you need and mark each as must-have at go-live, needed within a year, or nice to have. Most ERP programmes deliver in phases, and the ERP implementation roadmap guide shows how to choose what goes first.
Step 2: Count the things that create work
For each must-have module, count:
- Documents and records (sales order, delivery note, invoice, item, customer)
- Workflows and approval rules
- Calculations with business rules (pricing, commission, costing, tax)
- Reports and dashboards
- Integrations in and out
- Record types to migrate
Step 3: Size each item relatively
Give each item a size: small, medium, large or extra large. A simple master record with a list screen is small. A pricing engine with customer-specific rules, promotions and approvals is large. Relative sizing is faster and more honest than guessing hours, and it is easy for a vendor to challenge item by item.
Step 4: Add the non-feature work
Feature work is only part of the effort. Add allowances for:
- Discovery and solution design
- Project management and business analysis
- Testing (system testing plus support for your acceptance testing)
- Data migration, including trial loads and reconciliation
- Deployment, environments and security hardening
- Training, documentation and go-live support
Step 5: Turn effort into a range
The working formula is:
Estimated cost = total effort x blended team rate x (1 + contingency)
Use a range, not a single number. Contingency should be larger when requirements are vague, when data quality is unknown or when an integration partner's API is untested.
Illustrative example: sizing a distributor's first phase
The scenario below is illustrative. It shows the counting method, not real effort or prices.
A wholesale distributor with two legal entities wants finance, purchasing, inventory and sales in phase one, connected to an ecommerce store and a courier service.
| Area | Items counted | Sizes | Notes |
|---|---|---|---|
| Sales | Quotation, order, delivery, invoice, returns | 2 small, 2 medium, 1 large | Returns flow has credit and restock rules |
| Purchasing | Request, order, receipt, supplier bill | 3 small, 1 medium | One approval level |
| Inventory | Items, warehouses, transfers, stock count, batches | 2 small, 2 medium, 1 large | Batch tracking adds traceability reports |
| Finance | Ledger, receivables, payables, bank, inter-company | 2 medium, 2 large, 1 extra large | Two entities and inter-company postings |
| Integrations | Ecommerce orders, courier labels | 1 large, 1 medium | Order sync is two-way |
| Migration | Customers, suppliers, items, open invoices, stock | 3 small, 2 medium | Data in spreadsheets and an old accounting package |
The distributor now has a list a vendor can price line by line, and a clear view of where the risk sits: inter-company finance, two-way order sync and returns. Those are the items to explore in discovery or prove in a pilot.
Why do fixed ERP quotes before discovery mislead?
A fixed quote given before discovery is a guess with a margin added. Either the vendor has padded it to cover unknowns, or it will be followed by change requests once the real requirements appear.
Discovery turns assumptions into decisions: which approvals exist, how costing works, what data must move and which systems must connect. Until that happens, nobody can price the work accurately. Warning signs in a quote:
- A single total with no breakdown by module or phase
- No mention of data migration, testing or training
- Integrations listed as "API integration" with no named systems
- No statement of what happens when scope changes
- No assumptions section
A better structure is a paid or free discovery or pilot phase, followed by a priced scope based on what was learned. The software requirements brief template gives you a format for documenting scope before you ask anyone for numbers.
How do hosting and support change the cost after go-live?
The build is only the first cost. Once the ERP is live, you pay every year to host it, keep it secure and change it as the business changes, so ask for these lines separately from the build estimate.
- Hosting. Cloud resources for production, a test environment and backups. Cost rises with data volume, document storage and availability requirements, not usually with the number of users alone.
- Maintenance. Security patches, framework and library updates, and fixes. This work is unavoidable for any system that stays in use.
- Support. Help for users and investigation of problems. Response targets and support hours set the price more than anything else.
- Enhancements. New reports, new rules and new modules. Most ERP owners keep a yearly budget for this, because a system that never changes falls behind the business.
A vendor who quotes only the build has quoted part of the cost. The total cost of ownership model linked below shows how to put these yearly lines next to the one-off build.
What should you ask a vendor about its estimate?
Ask how the number was produced. A good estimate can be explained line by line; a weak one cannot.
- Which modules, workflows, reports and integrations does the estimate include, and which are excluded?
- What assumptions were made about data quality and migration volume?
- How much of the effort is testing, migration, training and project management?
- What contingency is included, and for which risks?
- How are changes to scope reviewed, priced and agreed before work starts?
- Who owns the source code and the data at the end of the project?
- What does support cost after go-live, and what response times does it include?
Checklist: what to prepare before asking for an ERP estimate
- List of modules ranked must-have, year-one and nice-to-have
- Number of legal entities, currencies and tax regimes
- Systems that must connect, with owner and whether an API exists
- Data sources to migrate, with rough record counts and known quality problems
- User roles and how many people in each
- Approval rules written as plain sentences
- The ten reports finance and operations cannot live without
- Languages and any right-to-left requirement
- Hosting preference and any data residency constraints
- Expected support hours after go-live
- Who in your business will make decisions and test
When is custom ERP not the cost-effective choice?
Custom ERP is not the cheaper route when your processes match standard practice and a packaged product covers them with configuration. In that case you pay for a licence and an implementation partner, and you benefit from a vendor roadmap you do not fund alone.
Custom development tends to pay off when the differentiating part of your operation (pricing, production, compliance workflow, a customer portal) does not fit a package without heavy customisation, or when licence costs grow with headcount in a way that hurts. The ERP vs custom development comparison covers that decision in detail, and the ERP total cost of ownership guide shows how to compare both options over five years rather than on the first invoice.
How to start
Prepare the checklist above, size your must-have modules with the counting method, and mark the three areas you think carry the most risk. If you are not sure how to structure the document, the ERP RFP template gives a fuller format for inviting several vendors.
Then discuss the project with us. Timeline Digital starts with a free pilot of 2 to 3 key modules before the full project, which gives you working software to judge and a scope based on evidence rather than assumptions. You can read more about how we build ERP modules and how scope, milestones and changes are agreed.