Short answer: Buy a package when your processes match your industry's standard shape. Build custom when your competitive advantage comes from how you operate rather than what you sell. The decision is not primarily about budget. It is about which side changes: with a package, the business adapts to the software; with a custom system, the software adapts to the business. Codefacture builds custom ERP and CRM systems for manufacturing, construction, logistics and healthcare operators.
The real difference
Off-the-shelf ERP such as SAP Business One, Microsoft Dynamics 365 Business Central, Odoo, NetSuite or Sage is built around the shared needs of thousands of companies and licensed as a finished product. Custom ERP is designed from your process map and used only by you.
Off-the-shelfCustomDirection of fitBusiness adapts to softwareSoftware adapts to businessTime to first use2 to 8 weeks8 to 24 weeksCost shapeLow entry, recurring licencesHigh entry, low maintenanceEffect of headcount growthIncreases cost directlyDoes notRegulatory updatesHandled by vendorHandled by you or your partnerSource codeNot yoursCan be yours by contract
When off-the-shelf is the right choice
Buy a package when your processes sit close to the industry standard, headcount is stable, and you need to be live quickly. A conventional distribution business, which purchases, stocks, sells, invoices and collects, runs the same way in tens of thousands of companies. Building that from scratch reproduces an existing solution at higher cost.
Four clear signals
Your processes are standard: orders, stock, invoicing, collections
You need to be operational within one to three months
You have fewer than 25 users and the number is not growing
You want statutory and e-invoicing compliance handled by the vendor
When custom is the right choice
Build custom when your operating model diverges from the industry standard, when user counts are high, or when processes have already leaked into spreadsheets because the package cannot hold them.
Five clear signals
You do configure-to-order, make-to-project or contract manufacturing. Customer-specific dimensions, materials and option combinations become permanent exceptions in a package.
Production plans, progress billing, commissions or discount matrices live in Excel. Every process that escapes the system is an argument for custom.
You have more than 50 users, or user count is climbing. Per-seat pricing that looks trivial at 15 users looks very different at 80.
You need a portal for dealers, subcontractors or customers. External-facing interfaces sit outside most packages' scope.
Data residency requirements mean the system must run on your own infrastructure.
A practical test: count how many times during a package demo the sales consultant said "you could also handle that this way." That count is your process mismatch.
Six-criteria decision matrix
CriterionPoints to off-the-shelfPoints to customProcess divergenceClose to industry standardMaterially differentUrgencyLive in 1 to 3 monthsCan wait 4 to 9 monthsUser countUnder 25, stableOver 50 or growingIntegrationsStandard: banking, e-invoicingMachinery, PLC, customer systemsInternal capacityNo one to own the projectA decision-maker can own itData residencyCloud is acceptableMust run on our infrastructure
Four or more marks in one column gives you your direction. A three-three split points to the hybrid model.
The hybrid model
In a hybrid setup, finance and accounting stay in a package while the differentiating processes such as production, field operations and portals run on a custom system, connected by API. For mid-sized companies this is frequently the most economical answer and it is what a large share of engagements end up as.
One decision makes or breaks it: define the single source of truth for each data type before you build. If the customer record is mastered in one system, everything else reads from it. Skip this and you will have two divergent customer lists within six months.
How to compare cost properly
Compare total cost of ownership over three and five years. The common error is setting a custom build's project fee against a package's annual subscription. These are not comparable figures.
Off-the-shelf cost stack
Licences or subscription, calculated as users multiplied by months multiplied by years
Implementation and consulting days
Customisation requests
Annual maintenance
Connector and add-on module fees
The cost of redoing customisations at each major version upgrade
Custom cost stack
Analysis and design
Development and testing
Data migration
Hosting infrastructure
Annual maintenance and support
[DATA BOX to fill before publishing: a real break-even example from a Codefacture project, with date and assumptions. User count, industry, and the month at which five-year totals converged. Without your own figures this section is indistinguishable from every competitor's.]
Three checks before deciding
Inventory your processes. Which run in the system, which run in spreadsheets? A long spreadsheet list answers the question for you.
Run the demo on your own scenario. Ask the vendor to process last month's most complex order end to end, not their prepared example.
Ask about exit cost. In what format, over what period and at what price can you extract your data? The answer measures your dependency.
Frequently asked questions
Is custom ERP more expensive than off-the-shelf?
Higher at the start, often lower over time. Package costs scale with user count and customisation, so the two curves typically converge around year three, and earlier with large user bases. Compare three-year and five-year totals rather than the initial figures.
How long does a custom ERP take to build?
With scope split into phases, a first working module is usually live within 8 to 12 weeks. Full replacement of a multi-department system takes considerably longer, which is why phased rollout is recommended over a single cutover.
Can we migrate from an existing ERP to a custom system?
Yes. Customer records, stock, product definitions and open transactions can be migrated. Data quality is the critical factor, and cleanup before migration is the most commonly underestimated part of the project. Historical detail is often archived rather than transferred.
Who owns the code for a custom ERP?
Whatever the contract states. Ownership, usage rights and actual source code delivery are three separate matters and all three should be written in. Client ownership of custom-built code is a standard and reasonable request.
Does the hybrid model actually work?
Yes, on one condition: define a single source of truth for each data type before building. Keeping accounting in a package while running production and field operations on a custom system is the most common and economical structure for mid-sized operators.