What does a custom ERP system actually cost?

It is the first question on every call and the hardest one to answer honestly. A custom ERP system is not a product with a price. It is a scope with a price, and until the scope exists there is nothing to put a number against.

That is not evasion. It is the difference between an estimate that holds and one that gets revised three times before anyone writes code. What follows is how the number is built, so you can either assemble a realistic budget yourself or recognise a quote that was guessed.

Why nobody will quote you a number on the first call

Two companies in the same industry, with the same headcount and the same turnover, can need ERP builds that differ several times over. The difference is almost never the industry. It is how many distinct workflows the business actually runs, how many of those have exceptions, and how many other systems have to be told what happened.

A distributor with one warehouse, one price list and one approval step is a modest build. The same distributor with three warehouses, customer-specific pricing, consignment stock sitting at a dealer, and a finance system that has to reconcile nightly is a different project wearing the same job title.

A number quoted before the workflows are written down is a number for an imagined project. It is not wrong because the vendor is dishonest. It is wrong because it is not about your business yet.

What you are actually paying for

It helps to split the cost into parts, because they do not scale together and they do not all arrive at once.

• Discovery. Collecting the registers, approvals, spreadsheets and handoffs your teams already use, and turning them into a written specification. Usually the smallest line, and the one that decides every other line.
• The data model and permission structure. One model, one set of roles, one audit trail. Settled before screens are designed, because it is the part that cannot be renegotiated later without pain.
• Module build. The visible work: screens, workflows, reports. Scales with the number of distinct workflows, not the number of users.
• Integrations. Each external system is its own small project with its own failure modes. Priced per integration, not per module.
• Data migration. Moving history out of the old system. Priced by how clean the old data is, which is rarely known at the start.
• Deployment and monitoring setup. Environments, release pipeline, alerting. Close to a fixed cost that does not grow much with scope.
• Training and rollout. Smaller than people expect when the software fits the job, and much larger when it does not.

The five things that move the price most

1. 01The number of distinct workflows, including the exceptions. Ten workflows with no exceptions is cheaper than four with six exceptions each. The exceptions are the real work, and they are what most scopes leave out.
2. 02How many systems have to agree. Every integration adds a contract to honour, a failure path to handle and a reconciliation to design. Two integrations is not twice one.
3. 03Whether roles are simple or political. Four clean roles is a week of design. A model where a regional manager sees some branches, approves up to a limit and can override one specific field is a different problem entirely.
4. 04The condition of the data you are bringing. Clean exports migrate quickly. A decade of a system people worked around does not, and nobody finds out which one you have until somebody looks.
5. 05How much has to be live on day one. All-at-once rollouts cost more than phased ones and carry more risk, because every unknown has to be resolved before anything goes live at all.

Phasing changes the shape of the cost, not just the total

A phased ERP programme does not simply spread the same money over a longer period. It changes what you are buying. The first release is deliberately narrow — one department, or one workflow end to end — and it exists to test the data model against reality before anything else is built on top of it.

That first release is where most of the expensive discovery actually happens, because theory meets somebody who does the job daily. Budgets that assume a flat per-module cost across phases usually have it backwards: module two is often cheaper than module one, because the hard decisions were already paid for.

It also gives you a real exit. If the first phase lands badly you have spent a fraction of the programme and learned something concrete. That optionality is worth paying for, and the way we sequence it is set out on how we work.

What sits outside the build price

Three costs fall outside the development quote and get missed often enough to be worth stating plainly.

• Infrastructure. Hosting, storage, backups and any paid third-party services the system calls. Modest for most mid-sized operations, but it is a monthly line forever.
• Your own people's time. Discovery, review and testing need the people who know the work. That time is real even though it never appears on an invoice.
• Keeping it alive. Dependency updates, security patches, monitoring and support after launch, covered under deployment, monitoring and support. What it costs to skip is the subject of post-launch software support.

How to get an estimate you can rely on

Ask for the estimate broken down by workflow rather than by phase or by month. A quote expressed as twelve weeks for phase one tells you nothing you can check. A quote expressed as nine days for order capture including its three exception paths can be argued with, and arguing with it is how it becomes accurate.

Then ask what happens when a workflow turns out to be more complicated than the scope said. Every project has at least one. A vendor with a clear answer has been here before. A vendor who says it will not happen has not.

A sanity check before you approach anyone

You can do most of the expensive thinking before you speak to a single vendor, and it will cost you an afternoon.

1. 01List every workflow the system must cover, in plain language, one line each.
2. 02Beside each one, write the exception that happens at least monthly. If you cannot name it, ask the person who does the job.
3. 03List every other system that must know the outcome, and mark whether data flows in, out or both.
4. 04Write down who may see what, by role.
5. 05Mark which of these must work on day one and which can wait six months.

That document is roughly two thirds of a usable scope, and it is the difference between quotes you can compare and quotes you cannot. How to write a software scope covers the rest.