ERPNext or a Custom Build? Decide It in an Afternoon
The question is usually framed as buy versus build, and framed that way it has no good answer. Five questions about your own processes settle it faster than a vendor comparison spreadsheet.
"Should we implement ERPNext or build something custom?" is the question we get asked most often, and it is the wrong shape. Framed as buy versus build it invites a vendor comparison, a feature matrix, and a decision made on the strength of a demo. Framed properly it is a question about your own processes, and you can answer it in an afternoon without talking to anyone.
The reason the binary is false is that on a framework like Frappe there is a third option, and it is the one most engagements land on: implement the standard product, then write real code where it stops short. Not configuration dressed up as custom development — actual doctypes, actual server logic, in a custom app that sits alongside ERPNext and survives its upgrades.
Five questions that settle it
1. Is this process your competitive edge, or just your habit?
Some processes are the business. A commodity trader's pricing logic, a hospital's triage flow, a distributor's route-settlement rules — get those wrong and the system is useless no matter how tidy the general ledger is. Those deserve custom work.
Most processes are not that. They are the way a previous system forced you to work, carried forward because changing it would mean retraining people. A three-step approval that exists because a 2014 tool could not do two. If you cannot explain what a process protects you from, it is a habit, and paying to rebuild it is paying to keep a constraint.
2. Does the standard doctype get you to roughly 80%?
Open the standard ERPNext document for the thing you are arguing about — Sales Order, Work Order, Patient Encounter, Employee — and list the fields and states you actually need against what is there. If most of it exists and you need four fields, two validations and a different print format, that is configuration plus a small custom app. If the standard document has the wrong shape entirely — wrong lifecycle, wrong parent-child structure, wrong unit of accounting — no amount of custom fields will fix it, and that module is a build.
3. What does your statutory surface look like?
This is the question that most often decides it, and the one most often left until last. GST, e-invoicing, ZATCA, payroll statutory filings — these are moving targets maintained by someone, forever. Every one you take on as custom code is one you now maintain yourself, including the year the format changes two weeks before the deadline. Standard product coverage of your jurisdiction is worth more than a long feature list.
4. How many systems does it have to talk to?
A build that only has to serve people is far cheaper than one sitting in the middle of five integrations. Count the interfaces: bank, payment gateway, logistics provider, marketplace, government portal, the legacy system nobody will decommission. Each one is an ongoing obligation, not a one-off task. The more of them you have, the more the framework's existing plumbing is worth.
5. Who maintains it in year three?
Bespoke software has an owner problem. If the answer is "the vendor who built it", then ask what happens if that relationship ends — which is why we hand over source code as a matter of course rather than as a concession. If the answer is "our own team", that team needs to exist and to know the framework. Custom work on top of a widely used open-source platform is far easier to inherit than a bespoke system nobody else has seen.
The three-year cost shape, honestly
A comparison that looks at licence and implementation cost only will always favour the build. Set the two side by side across three years instead:
- Implementation. A standard product implementation front-loads configuration and data migration. A build front-loads design and development, and its estimate is less reliable — not because estimators are careless, but because requirements for a bespoke system are discovered while building it.
- Change, year one. Both need changes after go-live. On the standard product many are configuration; on a build almost all are development.
- Statutory upkeep. Covered by the product's maintainers on one side; your line item on the other, every year, indefinitely.
- Upgrades. The framework moves. Custom code written as a proper app travels with it; custom code written into the core does not, and that is the bill people forget.
- Knowledge risk. Hardest to price, most likely to hurt. How many people outside your building could pick this up?
What this looks like in practice
A distributor came to us wanting a custom order-management system because "nothing handles our scheme discounts". The schemes were genuinely unusual — slab-based, retrospective, settled per route. Everything else they needed was ordinary: purchasing, stock across depots, receivables, GST.
Rebuilding all of it to accommodate one unusual module would have been paying to recreate the ordinary parts. Implementing the standard product and writing the scheme engine as a custom app meant one hard problem got real engineering attention and everything else was configuration. That is the shape most answers take, and it is why our implementation work and our custom development are usually the same engagement rather than alternatives.
Where our products fit
For some sectors we have already done the "extend the standard product" work and packaged it — the iSKEL suite is exactly that: the modules, statutory setup and reports a sector kept asking for, built once. If one of them covers your industry, it shortens the path considerably. If none does, the five questions above are still how we would scope it with you, in Solution Design, before anything is built.
Either way the deliverable of that conversation should be a written answer with reasons — which modules are standard, which are custom, and what each decision costs you later. If you want ours, start there.