What “custom module” means in ERPNext
In ERPNext, a module is a group of DocTypes, reports and pages that live inside a Frappe app. When people say they need a custom module, they usually mean one of three things:
- A brand-new area the standard product doesn’t cover, like equipment rental, clinic appointments or fleet maintenance.
- A heavy extension of something that exists, like adding territory rules and approvals on top of the standard CRM.
- Glue between ERPNext and another system, like syncing orders from Shopify or pushing payslips into a bank’s portal.
All three end up as the same thing on disk: a Frappe app with its own hooks.py, installed next to erpnext on your bench. erpfly generates that app. It doesn’t produce a zip of Server Scripts or a set of instructions for you to follow in the UI.
Why teams stop hand-building every module
Frappe is a good framework. The problem is that the work around a module is slow. Someone has to translate “the deposit gets refunded after inspection” into DocTypes, fields, a workflow, permissions and a controller. Then someone writes the report. Then someone remembers the print format. None of it is hard, but all of it takes days, and good Frappe developers are booked months ahead.
What erpfly does is compress that first 80%. You still decide what the module should do, and you still review what it produces. You just don’t wait three weeks to see a first version.
How a generated ERPNext app is laid out
If you open the pull request, you’ll see a structure any Frappe developer will recognise:
equipment_rental/
├── equipment_rental/
│ ├── hooks.py
│ ├── modules.txt
│ ├── patches.txt
│ ├── fixtures/ # custom fields, property setters, roles
│ ├── equipment_rental/
│ │ ├── doctype/
│ │ │ ├── rental_booking/
│ │ │ ├── rental_machine/
│ │ │ └── damage_inspection/
│ │ ├── report/
│ │ │ └── machine_utilisation/
│ │ └── print_format/
│ └── tests/
├── README.md
└── pyproject.tomlEach DocType has its JSON definition, a Python controller and, where needed, a small JavaScript form script. Business rules live in the controller or in functions wired up through doc_events. We keep Client Scripts to UI niceties and never put validation there, because anything enforced only in the browser can be skipped by the API.
Getting it onto your live site
Generated code is only useful once it’s running where your team works. There are three routes we see, and the app is the same in each.
Frappe Cloud. Connect the repository to your bench group, deploy, then install the app on the site. Migrations run as part of the deploy. This is the least work and what we’d pick for most small teams.
Your own server. On the box running bench, it’s the usual sequence: bench get-app with your repo URL, bench --site yoursite install-app, then bench migrate. If you already run other custom apps, nothing about this one is different.
CI pipeline. Larger teams tend to have a staging site that rebuilds on every merge. The generated tests run there with bench run-tests --app, and production only moves when staging is green.
Whichever route you take, we’d strongly suggest one habit: install on a copy of production first, with real data. Most surprises in ERPNext projects aren’t bugs in the new code. They’re old records that don’t fit a new mandatory field, or a naming series that clashes with something set up years ago. The generated patches handle the cases erpfly can see from your schema, and a staging run catches the rest.
When you should not use erpfly for this
We’d rather lose a sale than set you up badly, so here’s where we’d point you elsewhere.
- You need a feature that’s already in ERPNext. A surprising number of “custom module” requests turn out to be a setting. Check the ERPNext customization page first, and ask us if unsure.
- Your process isn’t settled yet. If three managers describe the approval flow three different ways, generating code won’t fix that. Agree on the process, then build.
- You need deep changes to accounting logic. We can generate them, but changes to GL entries deserve a senior ERPNext consultant in the loop. We’ll tell you when a request crosses that line.
Common modules people build on ERPNext
The most requested ERPNext modules we see are a CRM with territory rules, warehouse management with bin locations and pick lists, attendance with biometric device sync and invoice automation for things like milestone billing. Manufacturers often start with production planning and job cards.
If you’re not on ERPNext and are weighing it against Odoo, our ERPNext vs Odoo comparison sets out where each one is the better fit. And if neither fits, there’s always a custom ERP built from scratch.