How Much Does a Custom ERP Cost?

There is no list price, and anyone quoting one before seeing your operation is guessing. What actually drives the number, and how to work out your own.

There is no list price for a custom ERP, and any firm that quotes one before walking your floor is guessing at your scope and pricing the guess defensively.

That is an unsatisfying opening for a page you probably reached by searching for a number, so here is the useful version. The cost of a custom build is driven by five things, all of which you can assess yourself before you talk to anybody. And the comparison that actually decides it is not the build price in isolation. It is the build against what you are already paying, over the same number of years.

This page gives you the arithmetic rather than a figure, because the figure without the arithmetic is how people end up comparing a project quote against a monthly subscription and reaching the wrong conclusion.

The five things that actually drive the number

1. How many workflows are in scope. Not how many people, not how many machines. How many distinct processes have to work on day one. Quote to cash for a shop with 3 workflows is a fundamentally different build from one with 12, and this variable moves cost more than any other.

2. How many systems it has to talk to. Every integration is a surface that has to be built, tested, and maintained through the other system's upgrades. Two integrations is routine. Nine is a different project. The awkward ones are usually the old system with no API and the vendor cloud with a rate-limited one.

3. How consistent your process already is. A process that is written down and followed is cheap to build around. A process that varies by shift, by operator, or by customer has to be either standardised first or modelled in all its variation, and both cost real money. This is the variable people underestimate most.

4. What state your data is in. Migrating clean records is straightforward. Migrating twenty years of history where the same customer exists four ways and part numbers were reused after 2019 is archaeology, and it is billed like archaeology.

5. Whether you want to own it afterward. Handing over a development environment your team can actually use means building it to be handed over: documentation, structure, and training. That is real work and it is the work that determines whether you are buying an asset or renting a dependency.

Compare the shape, not just the number

The most common costing mistake is comparing a one-time project figure against a monthly subscription and concluding the subscription is cheaper. Over any horizon longer than about a year that comparison inverts, and the shape of the cost matters as much as the size.

ApproachCost shapeWhat makes it growWho pays for the next change
Big-suite ERPImplementation plus annual licenceSeats, modules, uplift clauseYou, per change request
Mid-market SaaS ERPAnnual subscriptionHeadcountYou, per change request
Open source, self-hostedStaffingYour engineering capacityYou, in engineering time
Partner buildProject, then optional maintenanceScope you choose to addYour team, after handoff
Internal buildSalaries, indefinitelyHeadcount and turnoverYou, if the developer stays

Notice that the growth column is where the divergence happens. A subscription that grows with headcount charges you more for succeeding. A build does not, which is the structural argument for it and has nothing to do with the day-one price.

How to work out your own number

You can get within a useful range before anyone quotes you. Four steps, and the inputs are all things you already have.

Step 1. Total your current annual software spend across every vendor in the quote-to-cash chain. Use the invoices, not the quotes, and include the add-ons and the support tier. This number is usually higher than the one people carry in their heads.

Step 2. Add the annual uplift. Check the clause. Project it forward 5 years and use that total, because that is the horizon a build is actually competing against.

Step 3. Add the labour you are spending on workarounds. The retyping, the reconciliation, the person who rebuilds the same report every Friday. Count the hours honestly and price them at loaded cost. This is the number that is invisible on every invoice and is often larger than the licences.

Step 4. Compare that five-year total against a project figure plus optional maintenance. If the build is a fraction of the five-year total, it is worth a serious conversation. If it is a large multiple, it probably is not, and a good partner will tell you so.

Most operations that do this arithmetic properly find step 3 is the surprise. The licences were known. The labour spent working around the licences was not.

What is cheaper than people expect, and what is not

Cheaper than expected: the first working workflow. Because the right approach ships one process rather than the whole company, the first useful thing arrives in weeks and costs a fraction of a full implementation. Most of the fear about custom builds comes from remembering year-long enterprise projects, which is a different animal.

Also cheaper than expected: ongoing change, if the handover was real. Your team adding a field should not be a line item.

More expensive than expected: data migration, every time. See driver 4.

Also more expensive than expected: process standardisation. If three shifts do the same job three ways, someone has to decide which way is correct before it can be built, and that decision is organisational rather than technical. It is often the longest pole and it is not really a software cost at all.

The contrarian part: the cheapest option is often to stay

If your operation genuinely fits your current system, your integrations work, and your renewal is not climbing, then replacing it is expensive change for its own sake. We have finished audits by telling clients exactly that.

The case for building gets strong when you are paying to fight the software: when your people maintain spreadsheets to bridge what the system cannot do, when a change means a vendor ticket and a quote, when the licence grows every year while the fit gets worse. Those costs are real and none of them appear on the invoice, which is why the arithmetic above matters more than any headline figure.

If you have not audited what you currently pay against what you use, that is the cheaper first step, and it sometimes ends with a renegotiation instead of a migration. The vendor evaluation exists for exactly that.

Questions we get

How much is ProShop ERP, or any other named system? We do not publish other vendors' pricing, because quoted numbers go stale and most of these are quoted per shop anyway. Ask them directly, and ask for the five-year number with every module you would need, the implementation, and the annual increase, rather than the per-seat headline. That is the figure that is comparable to anything else you are considering, including us.

Why will you not just publish a price? Because scope moves the number by an order of magnitude and a published figure would be either uselessly wide or quietly wrong for most readers. What we can do quickly is give you a real number for your operation once we understand the five drivers above, and that conversation does not cost anything.

Is custom always more expensive up front? Usually yes against a SaaS subscription, and usually no against a big-suite implementation, which carries its own substantial project cost before the licences even start. The comparison people should run is the five-year one.

What is the ongoing cost after the build? That is a choice. Some clients keep a maintenance arrangement for new work, others take it fully in house after handover and come back only for larger builds. The point of the handover is that the second option is genuinely available.

How does the return get measured? Against the workflow you started with, using its own before and after. The throughline across our clients is a return inside 60 days, and the reason it lands that fast is starting with the highest-friction process rather than the whole operation. At Newpark that first target returned 1,000+ hours a week.

What if we cannot afford the whole thing? Then do not buy the whole thing. Phased delivery is better practice anyway, because it produces feedback while corrections are still cheap. Starting with one workflow is both the lower-risk and the lower-cost path, and it is what we recommend regardless of budget.

How does this compare to hiring a developer? A developer is cheaper per month and carries key-person risk, which is the most common way internal builds fail. The question is whether the system survives that person leaving. The full comparison of building, buying, and partner-built covers where each one breaks.

What is next

Do the four-step arithmetic before you take any sales call, including ours. It takes an afternoon with your invoices and it changes the conversation, because you arrive knowing what the alternative actually costs rather than comparing a proposal against a feeling.

If you want a real number for your operation, tell us which workflow hurts most and roughly how many systems it touches. That is usually enough for a useful range. The readiness assessment takes 2 minutes if you would rather start there.