ERPNext Custom App Development with Frappe (2026)

ERPNext ships with accounting, stock, manufacturing and CRM (HR is the separate Frappe HR app), but no product fits every business exactly. The question is not whether to extend it but how, and the how decides whether the system stays maintainable or breaks on every update. I am Manoj; I lead ERPNext and Frappe programmes at MithTech, a team of Frappe specialists in Bengaluru, and I have seen both outcomes. When you want it built for you, see custom Frappe app development.

What decides whether an ERPNext system stays healthy is less how much was customised than whether the customisation lives in a proper custom app or was hacked into core.

What is an ERPNext custom app?

A custom app is a standalone Frappe application — a Python package scaffolded with the bench new-app command — installed onto your ERPNext site alongside ERPNext itself. ERPNext is built on the Frappe framework, and ERPNext is technically just one Frappe app among others. Your custom app sits at the same level, with full access to the same APIs, database layer, and UI.

That parity is the point. Your app can define new record types, add fields to ERPNext's DocTypes, run background jobs, expose REST endpoints and react to events, all from its own folder and Git repository. Nothing in ERPNext's source is touched, so an upgrade replaces ERPNext's files and leaves yours alone. For when to configure instead of code, and what drives the cost, see the ERPNext customization guide.

Skimmable summary: A custom app is a separate Frappe app installed beside ERPNext, with equal access to DocTypes, APIs, and events. Your logic lives in your own repository, so ERPNext upgrades leave it untouched.

What are DocTypes and how do they work?

A DocType is Frappe's core building block — a single definition that describes a table's schema, its form layout, its permissions, and its business logic all at once. Every record type you see in ERPNext, from Sales Invoice to Item to Employee, is a DocType. Creating a DocType generates the database table, the form, the list view, and the API automatically.

For custom development there are three ways to shape records:

Each DocType can carry a Python controller file — a class with lifecycle methods like validate, before_save, and on_submit — where your rules live. This is where genuine business logic belongs, versioned in your app and reviewable like any other code.

Skimmable summary: DocTypes define a record's schema, form, permissions, and logic in one place. Your app can add brand-new DocTypes, or attach custom fields and property setters to ERPNext's existing ones, each carried as a fixture.

Server scripts vs client scripts — what runs where?

Server scripts are Python that runs on the backend when a document event or an API call fires; client scripts are JavaScript that runs in the user's browser to make the form interactive. The two solve different problems. Server logic enforces rules and touches the database. Client logic reacts to what the user is doing on screen — showing a field, fetching a value, validating before submit.

Skimmable summary: Server scripts run Python on the backend for validation and data rules; client scripts run JavaScript in the browser for interactive forms. In-desk scripts are quick but live in the database — put real logic in your app's code instead.

How do hooks extend ERPNext without touching core?

Hooks are the central configuration mechanism of a Frappe app, declared in a single hooks.py file that tells Frappe how your app plugs into everything else. Hooks let your app intercept document events, override a DocType's controller class, replace a whitelisted method, inject CSS or JavaScript, and schedule background jobs — all without editing one line of ERPNext's source.

The hooks that matter most in day-to-day custom development:

Because everything routes through hooks.py, a reviewer can read one file and see every way your app touches ERPNext. That is what keeps a custom app auditable years later.

Skimmable summary: hooks.py is the one file that declares how your app plugs into ERPNext — reacting to document events, scheduling jobs, carrying fixtures, and overriding methods. It extends core behaviour without ever editing core files.

How do you build a custom app on ERPNext?

Building a custom app follows a repeatable path with Frappe's bench tool: scaffold the app, install it on your site, add DocTypes and logic, then export your customisations as fixtures so they travel with the code. The sequence below is the backbone every clean Frappe project follows.

If you do not have an in-house developer for this, the guide to hiring an ERPNext developer in India covers what skills to look for.

Skimmable summary: Scaffold with bench new-app, install on your site, add DocTypes and controller logic, export custom fields as fixtures, then migrate and test on staging. Git from day one, staging before production.

How do you keep a custom app upgrade-safe?

Upgrade-safety comes from discipline, not a single setting: keep every customisation inside your app, capture field changes as fixtures, and test on staging before any bench update. The reason matters — a version upgrade overwrites ERPNext's files. Anything you changed in core is lost, and a system built by patching core breaks on every update, which pushes teams to skip updates and end up on unsupported, insecure software.

Three habits keep an app clean. First, prefer fixtures and hooks over in-desk scripts so your logic lives in Git. Second, audit now and then: list every custom field, server script and hook, and delete those whose requirement is gone, because dead customisation is pure upgrade risk. Third, never skip staging; a full bench migrate on a copy of production shows conflicts before your users feel them. Built this way, a major release means testing and small fixes rather than rework, which is what the ERPNext v15 to v16 upgrade asks of a well-structured system.

Skimmable summary: Keep everything in your app, capture field changes as fixtures, audit and delete dead customisations, and always run bench migrate on staging first. Core edits are lost on upgrade — your app is not.

When should you build a custom app instead of configuring?

Reach for a custom app only when configuration genuinely cannot meet the need — a new record type ERPNext does not ship, a scheduled background job, a bespoke integration, an event-driven rule across DocTypes, or logic you want under version control. Most requirements, though, are configuration: custom fields, workflows, print formats, and dashboards need no app and carry no upgrade risk.

Building an app too early is the expensive mistake: it adds maintenance and testing for something the platform could have configured. The test: if it can be a Custom Field, a Workflow or a Property Setter, it should be. Keep the custom app for logic, integrations and record types only code can deliver. What ERPNext covers out of the box is on the Frappe and ERPNext page.

This post is part of the Frappe and ERPNext Architecture Guide. For the choice between a custom field, a custom app and a fork, read custom field, custom app or fork.

Skimmable summary: Build a custom app for new DocTypes, scheduled jobs, integrations, event-driven rules, and versioned logic. For fields, workflows, and print formats, configure instead — coding too early adds cost without benefit.

Frequently asked questions