A manufacturing client called me last year, convinced they needed SAP. Their reasoning: their largest customer used SAP, so clearly that's what "serious" companies run. They had 40 employees and were tracking inventory in three separate Excel files that nobody trusted.
They did not need SAP. They needed to stop arguing about which spreadsheet was correct.
That conversation happens more than you'd think. The ERPNext vs SAP debate gets framed as a budget question — cheap open source versus expensive enterprise — but that's not really the axis that matters. What matters is how weird your business processes are, how much internal capability you have, and whether you're solving a data problem or a workflow problem. Let me walk through how I'd actually think about it.
First: do you even need an ERP?
I'll lose a bit of business saying this, but plenty of companies who think they need an ERP need something much smaller.
An ERP earns its keep when multiple departments need to act on the same data and the handoffs between them are breaking. Sales quotes something that production can't build. Finance invoices for goods that never shipped. Procurement reorders stock that's sitting in a back room. That's an ERP problem.
If your actual pain is any of the following, an ERP is overkill:
- Leads and follow-ups falling through the cracks. That's a CRM problem. Something like Orbis Lead CRM solves it in weeks, not quarters, and costs a fraction of an ERP rollout.
- One department is disorganised. A focused tool for that team beats a company-wide system nobody asked for.
- Reporting is painful but the underlying data is fine. You may just need a BI layer on top of what you already have.
The cheapest ERP project is the one you correctly decide not to do. Genuinely. I'd rather tell you that now than 14 months into a stalled implementation.
ERPNext: the default I recommend most often
ERPNext is open source, built on the Frappe framework, and covers accounting, inventory, manufacturing, purchasing, sales, HR and projects out of the box. You can self-host it or use their cloud. There's no per-user licence tax if you self-host.
Where it genuinely shines
- Speed to value. For a business with reasonably standard processes, you can be live in 2–4 months, not two years.
- Customisation without a rewrite. Frappe lets you add custom DocTypes, fields, server scripts and workflows without forking the core. This is the underrated part. Most "we need custom ERP" requirements turn out to be ERPNext plus six custom doctypes.
- Cost predictability. Your spend is implementation and support, not escalating licence fees tied to headcount.
- You own your data. Self-host it and the database is yours, in a schema you can read.
Where it will frustrate you
- Deep industry compliance. Pharma validation, aerospace traceability, heavily regulated finance — SAP and its ecosystem have decades of certified modules here. ERPNext can be extended to comply, but you're building and validating it.
- Very high transaction volumes. It scales further than people assume, but if you're processing enormous daily volumes across dozens of legal entities, you'll be doing real performance engineering.
- Partner ecosystem depth. Good ERPNext implementers exist. There are far fewer of them than SAP consultants, and quality varies wildly.
- The UI is functional, not delightful. Your team will adapt. Some will complain first.
Realistic budget: a small-to-mid implementation typically lands somewhere in the low tens of thousands of dollars for scoping, configuration, data migration, integrations and training. Multi-entity or manufacturing-heavy builds go higher. Treat any quote under about $10k for a multi-department rollout with suspicion.
SAP: right for fewer companies than the branding suggests
I'm not anti-SAP. SAP is extraordinary software for the problem it solves — running a large, complex, multinational organisation with strict compliance obligations and a dedicated internal IT function.
Choose SAP (S/4HANA or Business One for the mid-market) when:
- You operate across multiple countries with genuinely complex tax, consolidation and statutory reporting needs.
- You're in a regulated industry where auditors expect a system they recognise.
- A large customer or parent company effectively mandates it.
- You can staff an internal team to own the system after go-live — not just during the project.
The part people underestimate isn't the licence cost. It's that SAP implementations tend to reshape your processes to fit the software rather than the reverse. That's often correct for a large enterprise — SAP's processes encode decades of best practice. It's usually wrong for a 60-person company whose competitive edge is doing something unusual.
And the honest warning: SAP projects fail on change management far more than on technology. If your team resents the system, no amount of licensing fixes that.
Custom ERP software: the narrow but real sweet spot
Building custom ERP software from scratch is the option I recommend least often and defend most strongly when it's right.
It makes sense when your core operational workflow is your business model, and no product models it. I've seen this in:
- Specialist logistics with unusual routing, consolidation or pricing rules
- Made-to-order manufacturing where every job has a bespoke bill of materials generated from customer specs
- Rental, leasing or asset-cycle businesses where the same unit moves through states no standard inventory module understands
- Businesses whose ERP is partly a customer-facing product
The trap is scope. "Custom ERP" that tries to replace accounting, payroll, inventory and CRM at once is how you spend two years and go live with something worse than what you had. The version that works is narrow: build the 20% that's genuinely unique, integrate the rest.
The pattern I actually recommend most
Nine times out of ten, the winning answer isn't ERPNext, SAP or custom. It's ERPNext as the backbone, with custom modules for the parts that make you different. You inherit accounting, inventory and purchasing for free, and spend your engineering budget only where it creates advantage. If you want to see the kind of thing that looks like in practice, some of our work follows exactly this shape.
This also sidesteps the worst outcome in the ERPNext vs SAP conversation: paying enterprise money for a system that still doesn't handle your one weird, critical process.
A decision framework you can use in 10 minutes
Question 1: How standard are your processes?
Write down your order-to-cash and procure-to-pay flows. If they'd be recognisable to any business in your industry, a product fits. If you keep saying "well, we do it differently because...", note each one. Those are your custom modules.
Question 2: Who owns this after go-live?
No internal technical owner? Choose the simplest system with the strongest support arrangement. This single question kills more ambitious ERP plans than budget does.
Question 3: What breaks if you do nothing for 18 months?
If the answer is "nothing catastrophic, it's just annoying", phase it. Fix inventory first. Fix finance next. Big-bang rollouts fail for reasons that have nothing to do with which vendor you picked.
Question 4: Where's your data now?
Data migration is consistently the most underestimated line item. Messy legacy data doesn't get cleaner by moving it. Budget real time for cleansing, and expect to run parallel for at least one full accounting period.
What I'd tell you over coffee
Under roughly 100 employees with normal processes: ERPNext, phased, with a partner who'll still take your calls in month nine.
Multinational, regulated, with internal IT: seriously evaluate SAP, and budget as much for change management as for the software.
Genuinely unusual operations: ERPNext core plus custom modules, or a tightly scoped custom build for the differentiated part only. We often pair this with automation and forecasting work — see AI & ML development — but only after the operational data is clean. AI on top of bad data just produces confident nonsense faster.
And if you're not sure which bucket you're in, that's a normal place to be. If you'd like a straight answer rather than a sales pitch, get in touch — send us your current process pain points and we'll tell you honestly what we'd build, what we'd buy, and what we'd leave alone.