Custom ERP vs Off-the-Shelf ERP: How to Decide and What Drives Cost
Buy or configure an off-the-shelf ERP when your processes are standard and the vendor's modules fit them. Build a custom ERP, or custom modules around a packaged core, when your workflows set you apart, workarounds keep multiplying or you need full control of data and integrations. On either route, cost follows scope, users, integrations, migration and upkeep.
Key takeaways
- Most businesses end up with a hybrid: a packaged core for accounting plus custom modules or portals for the work that differs.
- Compare both routes over several years, counting licences, implementation, customisation, integrations, migration, training, support and upgrades.
- Customisations on a packaged ERP must be re-tested at every vendor upgrade, so budget for that work from the start.
- Roll out one module at a time, beginning with the area that hurts most, and migrate its data with it.
- Whichever route you take, keep the data, database exports, code and hosting accounts in your own name.
On this page
Choosing between a custom ERP and an off-the-shelf product is rarely a clean either-or. Most businesses that ask the question are already running something: an accounting package, a few spreadsheets, a CRM that does not talk to the warehouse. The real decision is how much of the system to buy, how much to configure and how much to build, and what each choice will cost to own over the years that follow.
This guide explains what ERP is, lays out the routes side by side, shows when building pays off and when it does not, and lists the cost drivers on each route. It ends with how to roll out in phases and how to choose a partner.
What ERP is
SAP, one of the largest ERP vendors, defines enterprise resource planning as a software system that helps organisations streamline core processes such as finance, HR, manufacturing, supply chain, sales and procurement, with a unified view of activity. The important word is unified: one set of records that every department reads and writes, so an order, the stock it consumes and the invoice it produces stay linked.
In software development terms, ERP work means configuring, extending or building that system: its modules, data model, user roles, approvals, reports and the integrations that feed it. SAP's guide also notes that many smaller organisations start with standalone tools such as QuickBooks or Excel spreadsheets. That is usually where the ERP question begins, when the spreadsheets stop keeping up.
The four routes, from packaged to custom
ERP choices sit on a spectrum.
Off-the-shelf products. You subscribe to a ready-made system and adapt your processes to it. Examples, as their makers describe them:
- SAP Business One is SAP's all-in-one ERP for small and midsize businesses, covering accounting, purchasing, inventory, sales and customer relationships, with cloud or on-premise deployment.
- Microsoft Dynamics 365 Business Central is Microsoft's business management solution for small and mid-sized organisations, covering finance, sales, purchasing, inventory, projects and manufacturing.
- Odoo comes as an open-source Community edition and a licensed Enterprise edition, with separate apps for each business function.
- For smaller Indian businesses, TallyPrime covers accounting, inventory, statutory compliance, banking and payroll, and Zoho One bundles many Zoho business apps on one invoice.
Configure and extend. You take a packaged product and adapt it with settings, add-ons and custom code inside the vendor's framework. Business Central, for instance, is customised through extensions written in the AL language, and Odoo through Studio and custom modules.
Custom build. An ERP engineered around your processes, data model and users, which you own outright.
Hybrid. A packaged core, usually accounting, with custom modules, portals or integrations around it. This is the most common real-world answer.
| Route | What it is | Fits when | Main trade-off |
|---|---|---|---|
| Off-the-shelf | A ready-made ERP you subscribe to or license | Processes are standard and the product's modules match them | You adapt to the product; changes depend on the vendor |
| Configure and extend | A packaged ERP with add-ons and custom code inside its framework | Mostly standard processes with a few important variations | Each customisation must survive every vendor upgrade |
| Custom build | Software engineered around your processes and data | Workflows are a differentiator, or nothing packaged fits | You own it, and you carry the build and the upkeep |
| Hybrid | Packaged core plus custom modules, portals or integrations | Accounting is standard but operations are not | Two systems to integrate and keep in step |
Custom ERP vs off-the-shelf: a decision table
Score your situation against each row. If most answers sit in one column, that is your starting point.
| Question | Points to off-the-shelf | Points to custom or hybrid |
|---|---|---|
| How standard are your processes? | They look like your competitors' | Pricing, production or service workflows are how you win |
| How many workarounds do you run today? | A few, and the product handles them | Staff re-key data, keep side spreadsheets or chase approvals by email |
| How soon must it go live? | Weeks to a few months | You can phase a build, module by module |
| How many systems must connect? | Mostly the vendor's own apps | Several in-house, legacy or industry systems |
| How do licence costs grow? | User numbers are stable | Many occasional users, field staff or partners would each need a seat |
| Who will maintain it? | You want the vendor to own upgrades | You have, or will contract, an engineering team |
| How much control of data do you need? | Vendor hosting and export tools are enough | Specific audit trails, residency or reporting needs |
When a custom ERP pays off
- The process is the product. A manufacturer with unusual batch costing, or a service firm whose billing mixes retainers, milestones and annual maintenance contracts, gets little from forcing that logic into generic screens.
- People are the integration layer. If staff copy orders between a sales tool, a warehouse spreadsheet and the accounting package, the missing connections are the system you need.
- Workarounds have become the system. When the packaged ERP needs so many add-ons and side tools that the add-ons carry the business logic, purpose-built modules can be cheaper to run.
- You need to own the data model. Reporting, audit or integration needs that the vendor's schema cannot meet.
When building does not pay off
Building is not free control. A thread on Reddit's r/Sage put the trade-off plainly: building "eats time, money, and bandwidth", while buying is faster but leaves you "stuck with what the vendor offers". Another, on r/agile, was titled "Custom ERP software development seems never-ending", because someone has to decide on everything, fix bugs and keep maintaining it.
Both are fair warnings. Buy when your accounting, payroll and tax compliance are standard, because a mature product has already absorbed years of edge cases and statutory changes. Do not build a custom general ledger to save licence fees; build the parts that differ. If you cannot name a business owner for every module, the project will drift.
What drives cost on each route
No honest figure exists before someone has mapped your processes. What moves the total on each route:
Off-the-shelf and configure-and-extend
- Licences per user. Odoo's paid plans, for example, are charged per user per month, and its Custom plan is needed for Studio, custom developments, the external API and on-premise hosting. Zoho One's all-employee pricing requires a licence for every employee.
- Implementation. Odoo's pricing page states that implementation services are not included in its plans. Partner or vendor time to configure, test and launch is a separate line.
- Customisation and add-ons. Each extension adds build and test effort.
- Upgrades. Business Central online receives two major updates a year, in April and October, and Microsoft recommends keeping extensions ready to update and testing them. Odoo's upgrade documentation says the maintainer of a custom module is responsible for making it compatible with each new version.
Custom build
- Scope. The number of modules, user roles, workflows and approval chains.
- Integrations. Each connected system adds design, testing and failure handling.
- Data migration. Cleaning and moving records from the tools being replaced.
- Reporting and compliance. GST invoicing, audit logs, statutory reports.
- Hosting, support and maintenance after launch, which never stop.
Both routes
- Integrations, data migration, training and change management.
- Ongoing support, and the internal staff time spent on testing and decisions.
Fee models differ too: per-user subscriptions for packaged products, and for custom work usually a paid discovery followed by fixed-price phases or time and materials. Compare quotes over the same multi-year period, with every line above included. See the engagement models for how build teams are commonly structured.
Phased rollout, module by module
Large ERP launches fail in the same way: every department changes at once and nobody trusts the new numbers. A phased rollout reduces that risk.
- Map processes and owners. How orders, money, stock and people move today, and who owns each record.
- Pick the first module. The area with the most pain or value, often finance, inventory or sales.
- Design the shared data model around that module, leaving room for the next ones.
- Migrate that module's data, run it alongside the old process briefly, then switch.
- Add the next module once the first is in daily use and the gaps are fixed.
The same approach works for a hybrid: keep the packaged core live and add custom modules around it one at a time, connected through API integration.
Data ownership
Whoever controls the database controls your options later. For a packaged ERP, check how you can export complete data, in what format, and what happens to it if you leave. For a custom build, insist that the source code, database schema, cloud accounts and documentation sit in your name from day one. Replacing an older in-house system is a legacy modernisation project in its own right, and the data migration usually takes more effort than the new screens.
Risks and trade-offs
- Scope creep. Custom projects grow when every request is accepted. Fix the first release and keep a backlog.
- Customisation debt. A packaged ERP customised beyond recognition combines the costs of both routes.
- Vendor dependence. Licence terms, plan changes and product roadmaps sit outside your control.
- Key-person risk. A custom ERP that one developer understands is fragile. Ask for documentation and automated tests.
- Adoption. Training and a staged switch matter as much as the software.
How to choose an ERP development partner
- They map processes before quoting. A price from a feature list is a guess.
- They will recommend buying where it fits. A partner who proposes a build for every problem is selling.
- They show working modules early, in short cycles with demos.
- They name the team and its seniority.
- Migration and integrations are line items, with a plan for each source system.
- Ownership is in writing: code, schema, accounts and documentation.
- Support terms are explicit, including how upgrades and changes are priced.
Our custom app development company guide covers the general build-or-buy checklist in more detail, and Odoo vs Shopify compares a packaged ERP with a commerce platform.
How Mindrops works on this
Mindrops builds custom and modular ERP systems and extensions around existing ones. For a digital services agency it built a custom web ERP with nine integrated modules, including CRM, projects, tasks, timesheets, GST invoicing, payments and recurring AMC billing, on React and PostgreSQL. For Barbeque Nation it built a partner portal for vendor onboarding, contracts and live ledgers, with the existing ERP kept as the system of record. That is the hybrid route in practice.
Work starts by mapping processes and choosing the first module, then proceeds module by module with data migrated from the tools each one replaces. Delivery follows CMMI Level 3 processes, and the client owns the source code, database and infrastructure. Mindrops has offices in New Delhi, London and Brussels; for local context, see the guides to ERP development in Pitampura and ERP development in Rohini. Broader builds sit under custom software development. To talk through which route fits, send a brief through get a quote; Mindrops replies as quickly as possible.
Conclusion
Buy the commodity parts, build the parts that set you apart, and connect them properly. Price every route over several years, roll out one module at a time, and keep your data and code in your own name. A custom ERP pays off when it removes real workarounds; rebuilding what a packaged product already does well rarely does.