Custom ERP Development Cost: Build or Buy, With Both Numbers
A custom ERP phase one runs 1,000 to 1,900 hours. At $40 per hour that is $40,000 to $76,000, at $100 per hour $100,000 to $190,000, and at a $65 blended rate $65,000 to $123,500.
The comparison you actually want is against a licence, and here is the problem with making it: most ERP vendors will not tell you the price. Checked on 14 October 2026, NetSuite, SAP Business One and Acumatica publish no list price a buyer can plan against. Microsoft publishes Dynamics 365 Business Central at $80 per user per month for Essentials and $110 for Premium, paid yearly. Odoo publishes too, though it localises by region.
So the honest build-or-buy answer uses the one major mid-market ERP that shows its number. Against Business Central Essentials, the crossover is a user-count question before it is a feature question. At 25 users a build pays back in 2.7 to 5.1 years. At 50 users, 1.4 to 2.6. At 100 users, under 18 months on either end of the build band.
Most comparisons skip this because they cannot source the licence side, so they argue about features instead. Features are the part both options can usually satisfy. The number of seats is the part that decides the money, and it is knowable today.
The 1,000 to 1,900 band is phase one of a manufacturing ERP: the item model, costing, production documents, stock and valuation, and the integrations that connect them to whatever you keep.
The spread is not vagueness. A domestic maker with two buyers, one job worker and no export paperwork sits near the bottom. A vertically integrated exporter, with buyers who each impose their own document formats and several outsourced production stages, sits near the top on several modules at once. Ask which of those two you are before reading any total, including ours.
The module-by-module breakdown lives in our garment ERP post, which prices a worked 1,400-hour example line by line. This post is about the comparison rather than the composition, so the table is not repeated here.
What the band does not include is as important as what it does. Shop-floor terminals and scanning hardware sit outside it. So does any selling surface, whether a B2B portal or a channel integration. So does migrating more than one season of history, because the cost of that scales with the variety of your records rather than their number, and with whether the units are consistent. A single season in mixed units costs more to move than three seasons in consistent ones, which is a sentence worth re-reading before anyone agrees a migration scope.
Business Central Essentials at $80 per user per month is $960 per user per year. Set that against a one-off build at the $65 blend and the arithmetic is simple.
Users | Licence per year | Crossover, 1,000 h build | Crossover, 1,900 h build |
25 | $24,000 | 2.7 years | 5.1 years |
50 | $48,000 | 1.4 years | 2.6 years |
100 | $96,000 | 0.7 years | 1.3 years |
200 | $192,000 | 0.3 years | 0.6 years |
Below about 25 seats, the package almost always wins on money. Above about 100, a build pays for itself inside two years on licence fees alone, and that is before any of the softer arguments. The interesting band is 25 to 100, which is where most manufacturers and distributors actually sit, and where the decision turns on the things the licence number does not include.
A seat price is not a cost of ownership, and the gap is usually larger than the licence.
Implementation. Configuring a package to a real operation is a project with consultants, data migration and a parallel run. It is routinely reported as the largest single line in an ERP programme, often a multiple of the first year's licence. Those reports come from third-party aggregators rather than vendors, so treat them as a prompt to get a written quote rather than as a figure to plan with.
The seats you forget. Business Central's $8 Team Members tier covers light read and approve use. Anyone doing real transactional work needs a full seat, and the count that ends up on the invoice is usually higher than the count in the business case.
Annual increases. A licence is a subscription, so the comparison above is conservative: it holds the per-seat price flat for five years, which no subscription has ever done.
The cost of fitting your operation to the software. This one never appears on any invoice. It shows up as a process changed to suit a screen, and it is only free if the process was arbitrary to begin with.
Customisation, which is where packages get expensive quietly. Every package permits configuration, and most permit extension. The first is free and the second is a development project with a vendor's constraints attached, priced by a partner, and re-tested at every upgrade. The honest question during evaluation is not "can it do this" but "is this configuration or extension", because the two sit on opposite sides of the cost line and demos rarely distinguish them.
Upgrade work. A package upgrades on the vendor's schedule, not yours, and every extension you added has to survive it. That is a recurring cost with no line on the quote, and it is the one most likely to be discovered in year three.
Fairness cuts both ways, and a build has recurring costs a one-off figure hides.
Hosting runs monthly and forever. So does maintenance: dependency updates, security patches, and the changes that follow when a regulator, a buyer or a bank changes a format. Filing and transmission fees, where they apply, are per document and belong in operating cost rather than the build estimate.
And a build carries a risk a package does not: it can be wrong. A package is a bet that someone else's model of your industry is close enough. A build is a bet that you understand your own operation well enough to encode it. Neither is free of risk; they are different risks, and the second is the one discovery exists to reduce.
Most of the time, honestly, for most of the stack.
If your processes are ordinary and your seat count is low, a package will beat a build on money and on time to value, and the right move is to adopt its assumptions rather than fight them. General ledger, tax and statutory output are solved problems where a package will beat bespoke work, and they are not where your business differs from a competitor's.
The test is not whether a package *can* do something. Given enough configuration, it usually can. The test is what the configuration costs you in the process it forces, and whether that process is one you are indifferent about.
There is a second case for buying that has nothing to do with money: speed to a working system when the operation is the thing being figured out. A business still deciding how it wants to run is a poor candidate for encoding its processes in software, because the encoding will be obsolete before it ships. A package imposes a working model immediately, and an imposed model you can critique beats a bespoke one you specified before you knew the answer. Build later, once the process has stopped moving and you can say precisely where it differs.
DoraDori is a garment ERP we built on FastAPI over PostgreSQL, owned end to end rather than added as a module inside a general platform. The reason is specific, and it is the clearest example of when custom wins.
Apparel has three item levels: a style, a colourway, and a variant of style, colour and size. Only the variant physically exists. Demand follows a size curve, and fabric cost comes off the marker rather than a price list, which makes costing yield-driven.
Three levels, a size dimension and yield-driven costing are expensive to bolt onto a flat item master. They touch the item master, the stock model and the costing engine at once, which forces those changes onto a product that has no use for them. You end up patching two codebases instead of one, while tenancy, access control and deployment get solved again rather than inherited.
There is a second tell in the same build. A general ERP posts one material variance against an order. Apparel needs five, because the ways fabric is lost — at the end of a roll, at a splice, to shrinkage, to cutting, to rejects on the line — have different owners and different fixes. A combined figure tells nobody which to work on, so the people who need it stop trusting the system and go back to a spreadsheet. That is not a reporting gap you configure away; it is a consequence of how the package models a variance.
That is the shape of a genuine build case: not a feature the package lacks, but a model the package contradicts. The practical test during evaluation is to take the two or three numbers your business argues about most, and ask the vendor to show you where each one lives. If the answer requires an extension, you have found the contradiction.
Build-or-buy is a false binary, and the most common right answer is neither.
Cheersagar keeps its books in Zoho and its customer relationships in an internal CRM. The problem was not that either system was wrong. It was that answering an ordinary question — which style is earning, which customer is slow, how this month reads against the last — meant exporting from both and joining them by hand in a spreadsheet. The second problem was that nobody wanted a new place to look.
So we built the layer between them rather than a replacement for either: the integrations, the reporting the business runs on, and an AI layer that writes the read on a number without producing the number itself.
That is usually the cheapest correct answer, and almost nobody quotes it, because it does not fit either sales motion. A package vendor sells you a package. A development shop sells you a build. The layer between two systems you already have is smaller than both and solves the actual complaint, which was never "we lack a system" but "we cannot see across the two we have".
Every one of these options leaves you with two or more systems that each hold part of the truth, and the expensive mistake is not choosing wrongly between them. It is leaving the line between them undefined.
On DoraDori the accounting boundary with Zoho was drawn once early and never revisited. The consequence is that a handful of figures have two plausible homes, and which one is authoritative became convention rather than design. Nothing breaks. People just learn, informally, which screen to trust for which number, and that knowledge lives in heads rather than in the system.
Write down, per figure, which system settles it. When a number is disputed the ERP is not automatically the winner, and knowing which system wins which argument is part of running the thing rather than a detail of building it. This costs an afternoon during discovery and is close to unrecoverable afterwards, because by then both systems have a year of history behind their version of the same number.
The same applies to the published reads that other systems consume. On DoraDori two of them carry most of the integration surface: what a style is made of and what is on hand, and what fabric is worth rather than how much there is. Because they are read from outside, they are a contract rather than an internal function, and neither can change shape on the ERP's own schedule. Deciding which of your reads are contracts, early, is what stops a later release breaking somebody else's system.
Four steps, in order.
Count the seats honestly, splitting full users from light approve-and-read users, because that split moves the licence number more than any discount will.
Get the licence quote in writing, from the vendors who will not publish. The absence of a list price is not a reason to leave them out; it is a reason to make them commit. A vendor that will not put a number on paper during evaluation will not become more flexible after you have migrated.
Price the build from hours, not a total. Ask which modules, at what hours, inside what published range. A single number with no composition behind it cannot be argued with, which is precisely why it is quoted that way.
Then compare like for like over five years: licence plus implementation plus annual increases, against build plus hosting plus maintenance. If one side of that sum is missing a line, the comparison is decoration.
Not cost. Cost tells you the crossover, and the crossover is arithmetic anyone can do once both numbers exist.
The decision is whether your operation differs from the industry's standard model in ways that make you money. If it does not, adopt a package and change your processes to match it, because the difference was accidental rather than valuable. If it does — if the way you cost a garment or route a delivery or reconcile a job worker is the reason customers choose you — then encoding that into someone else's data model is not a saving. It is paying to become more ordinary.
Most companies are the first case for most of their stack and the second case for one part of it. The build is for that part. The licence is for the rest.
A phase one runs 1,000 to 1,900 hours depending on scope. At $40 per hour that is $40,000 to $76,000, at a $65 blended rate $65,000 to $123,500, and at $100 per hour $100,000 to $190,000. The spread reflects the business rather than the software: a domestic maker with one outsourced production stage and no export paperwork sits near the bottom, and a vertically integrated exporter near the top. Hosting and maintenance are recurring and sit outside that figure.
It depends almost entirely on seat count. Against Dynamics 365 Business Central Essentials at $80 per user per month, a custom build pays back in 2.7 to 5.1 years at 25 users, 1.4 to 2.6 years at 50, and under 18 months at 100. Below roughly 25 seats a package nearly always wins on money. Above 100 a build pays for itself on licence fees alone within two years. Between those, the decision turns on whether your operation differs from the package's assumptions in ways that earn you money.
Most sell through partners and price per deal, so a public number would constrain negotiation. Checked on 14 October 2026, NetSuite, SAP Business One and Acumatica published no list price a buyer could plan against. Microsoft publishes Dynamics 365 Business Central at $80 per user per month for Essentials and $110 for Premium, paid yearly, and Odoo publishes with regional localisation. For the rest, insist on a written quote during evaluation; a vendor that will not commit a number on paper before you migrate will not be more flexible afterwards.
Implementation, which is routinely the largest line in the programme and is reported by third-party aggregators at a multiple of first-year licence. The seats you forget, because light read-and-approve tiers do not cover transactional work. Annual subscription increases, which make any flat five-year projection conservative. And the cost of fitting your operation to the software, which never appears on an invoice and shows up instead as a process changed to suit a screen.
When the package contradicts your model rather than merely lacking a feature. Apparel is the clean example: three item levels, a size dimension and yield-driven costing touch the item master, the stock model and the costing engine at once, so adding them to a general platform means changing its core and maintaining two codebases. A missing feature is a configuration problem. A contradicted model is a build case, and the difference is worth establishing before anyone quotes either option.
Usually, and it is often the cheapest correct answer. In the Cheersagar build the books stayed in Zoho and the customer records in an internal CRM, and we built the layer between them: the integrations and the reporting the business runs on. The complaint was never a lack of systems, it was an inability to see across the two already in place, which had meant exporting from both and joining them by hand in a spreadsheet. Almost nobody quotes that option, because it does not fit either a package sale or a full build.
The hours are the honest unit, and the calendar follows from team size and your availability rather than from a promise. What paces these projects is operational: getting the integration inventory for every system the ERP must talk to, at the version you actually run rather than the version in the documentation, and deciding which system is authoritative for each figure that two of them could claim. Both are discovery work, and both are cheaper to settle before a start date than after one.
Vikas has around fifteen years of experience building software and now builds generative AI systems at Zyneto. His work covers retrieval augmented generation, agentic AI, knowledge graphs, AI memory, and the evaluation and guardrails that decide whether any of it is safe to put in front of customers. He has shipped enterprise copilots, document AI, chatbots and predictive analytics for e-commerce, fintech and marketing teams, and works day to day in Python, JavaScript and SQL. He follows multimodal models, business process automation and enterprise AI security closely, and mentors engineers moving into AI. He writes about architecture, inference cost and the failure modes that only show up at production scale.
Share your details and we will talk soon.
Be the first to access expert strategies, actionable tips, and the trends actually shaping the digital world. No fluff - just practical insights delivered straight to your inbox.
Dive into our blog and stay ahead of the curve with expert perspectives, future-ready trends, and tech tips written for decision-makers and doers alike.
