Most Companies Should Not Build a Custom ERP

Most engineering teams underestimate what a custom ERP actually is. This post breaks down where bespoke ERP makes sense, where it does not, and what the real costs look like before you commit.

What "Custom ERP" Actually Means in Practice

An ERP is not a single application. It is a set of interconnected modules that share a common data model: inventory, procurement, finance, HR, production planning, and whatever else your operations touch. When those modules are built in-house, every integration point is your responsibility. Every schema migration. Every permission model. Every audit trail.

Off-the-shelf platforms like SAP S/4HANA, Oracle Fusion, or Microsoft Dynamics 365 ship with decades of domain logic baked in. That logic is not glamorous. It covers things like FIFO vs. AVCO inventory costing, multi-entity consolidation, GST/TDS compliance, and approval workflows with delegation chains. None of that is interesting to build. All of it is expensive to get wrong.

Custom ERP makes sense when your processes are genuinely differentiated, when off-the-shelf platforms cannot be configured to match them without destroying the differentiation, and when you have the engineering capacity to maintain what you build indefinitely. Those three conditions rarely coincide.

What Does a Custom ERP Actually Cost?

The build cost is the number most teams anchor on. It is also the least important one.

A reasonable mid-complexity ERP covering procurement, inventory, finance, and one operational domain (say, manufacturing or logistics) takes a team of six to ten engineers roughly 18 to 24 months to reach production readiness. At market rates in India, that is ₹2–4 crore in engineering salaries alone, before infrastructure, QA, security audits, and product management. In a Western market, multiply by three to five.

That figure assumes your requirements are stable. They never are.

After go-live, a custom ERP needs ongoing maintenance at roughly 20–30% of the initial build cost per year. That covers regulatory changes (GST rate revisions, TDS section amendments, Companies Act updates), OS and dependency upgrades, performance tuning as data volumes grow, and the inevitable "can we add one more thing" requests from finance.

The hidden cost is opportunity cost. Every engineer maintaining your ERP is not building the product that differentiates you in the market.

When the maths does work

If your core operations are your product, the calculus changes. A 3PL with a proprietary slotting algorithm, a contract manufacturer with custom MES integrations, a platform business where the ERP is customer-facing: these are cases where a custom system can be worth it. The test is whether the ERP contains logic that a competitor cannot replicate by buying the same SaaS licence.

Should You Customise an Existing Platform Instead?

This is the question most teams skip past too quickly.

SAP, Oracle, and Dynamics are highly configurable. So are mid-market platforms like ERPNext (v16 on Frappe Framework), Odoo 17, and Zoho ERP. ERPNext in particular is open-source, Python/JavaScript-based, and has been production-tested in manufacturing, distribution, and services contexts across thousands of deployments. You can fork it, extend it with custom doctypes, and write custom scripts without touching the core.

Approach	Upfront Cost	Ongoing Maintenance	Vendor Lock-in	Flexibility
Off-the-shelf SaaS (e.g., Dynamics 365)	Medium (licence + implementation)	Low (vendor handles upgrades)	High	Low
Open-source platform (e.g., ERPNext)	Low-Medium (implementation + hosting)	Medium (self-managed upgrades)	Low	Medium-High
Fully custom build	High	High	None	Full

The open-source middle path is underused. You get source access, full data ownership, and a community-maintained domain model, without carrying the full cost of greenfield development. The tradeoff is that you are still constrained by the platform's data model. If your requirements genuinely do not fit, that constraint becomes a ceiling.

What Are the Signs Your Team Is About to Make the Wrong Call?

There are patterns that reliably precede a bad custom ERP decision.

The most common: the team has evaluated one or two SaaS platforms, found gaps, and concluded that building from scratch is the only option. Gaps in a SaaS platform are normal. The question is whether the gap is in a differentiating process or a commodity one. If finance wants a non-standard payment approval flow, that is almost always configurable. If your warehouse uses a bin-location scheme that no platform supports, that is worth investigating further, but it is also almost certainly solvable with a custom module on top of an existing platform rather than a ground-up build.

The second pattern: the project is led by operations rather than engineering. Operations teams describe what they need in terms of current process. Engineers need to identify which of those requirements are incidental to the current process and which are load-bearing. Without that translation layer, you end up building a digital replica of a paper form, which is a waste.

The third: the company is pre-revenue or pre-scale. At that stage, you do not know what your processes will look like in 18 months. Building an ERP on assumptions that will change is expensive. Use SaaS, accept the friction, and revisit when the processes have stabilised.

What to Do if You Do Need a Custom System

If you have worked through the above and concluded that a custom build is genuinely warranted, a few things matter more than most teams expect.

Start with the data model, not the UI. The hardest problems in ERP are about data consistency across domains: stock movements that must reconcile with ledger entries, purchase orders that cascade into GRNs and then into AP invoices. Get the schema and the transaction boundaries right before you write a single React component.

Choose boring technology for the core. PostgreSQL for storage. A well-understood backend framework (Django, Rails, or Spring Boot depending on your team's depth). Event sourcing only if you have a specific auditability requirement that justifies the operational complexity. The ERP will outlive whatever was trendy when you built it.

Build the finance module last, or buy it. Accounting is a solved problem with a 500-year-old standard (double-entry bookkeeping). Building a general ledger from scratch when Tally, QuickBooks, or Xero APIs exist is a decision you will regret when your auditors ask questions you cannot answer.

Finally, staff it as a product, not a project. A custom ERP without a dedicated product owner and at least two engineers on retainer will decay. That is not a prediction; it is a pattern we have seen repeatedly.

Conclusion

The default answer to "should we build a custom ERP" should be no. Not because building is always wrong, but because the conditions under which it is right are specific, and most teams have not verified that those conditions apply to them.

If your processes are genuinely differentiated and you have the team to sustain what you build, a custom system can be the right call. Otherwise, ERPNext or Odoo with targeted customisation will cover 80–90% of your requirements at a fraction of the cost and risk.

Before committing either way, map your processes against a real platform for two weeks. The gaps you find will tell you more than any architectural discussion.

---

FAQ

Is ERPNext good enough for a manufacturing company with 200+ employees? ERPNext is production-tested in manufacturing environments well beyond that scale. It covers MRP, BOM management, work orders, subcontracting, and quality inspection out of the box. The constraint is usually implementation quality, not platform capability. A properly configured ERPNext instance handles multi-plant operations, multi-currency, and GST compliance without customisation.

How long does a custom ERP typically take to build? A mid-complexity system covering four to five operational domains takes 18 to 24 months with a team of six to ten engineers before it is genuinely production-ready. Timelines that promise less are usually scoping something narrower than a full ERP or underestimating what "production-ready" means for financial and compliance modules.

What is the biggest technical risk in a custom ERP project? Data integrity across module boundaries. Stock, procurement, and finance modules all write to shared state. Without carefully designed transaction boundaries and reconciliation mechanisms, discrepancies accumulate silently. They surface during audits, not during development, which makes them expensive to fix.

Can we start with a custom ERP and migrate to SAP later? Yes, but the migration cost is almost always higher than teams expect. Data model differences between a bespoke system and SAP's application tables are significant. Plan for three to six months of data migration effort alone, plus parallel-run periods for finance. If SAP is the long-term destination, it is worth asking whether you should start there with a lean implementation.

What should we build custom even if we adopt an off-the-shelf ERP? The integrations to your proprietary systems, any customer-facing workflows that expose ERP data, and reporting layers that aggregate across multiple data sources. These are areas where off-the-shelf platforms are consistently weak and where custom development delivers genuine value without requiring you to own the entire ERP stack.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.