Custom Frappe app development for the workflows ERPNext doesn't cover

Frappe is a full-stack web framework in Python and JavaScript with one unusual idea at its centre: the data model is metadata. A doctype defined in the framework produces the database table, the form and list views with filters and saved reports, a REST API with pagination and filters, role and field-level permissions, document versioning, comments, assignments, email and notification hooks, and a workflow engine — all without code. Around that sit background jobs on Redis Queue, real-time updates over socket.io, a report builder, print formats, a multi-tenant bench that runs many sites on one installation, and a mature upgrade path. For the kind of application most organisations actually need — records, rules, approvals, reports — that is roughly 80 % of the work already done.

That is also the honest boundary. Frappe is the right choice when the application is about business records and the people who act on them; it is the wrong choice for a high-throughput consumer product, a UI-first application where the interface is the product, or a domain that is not relational. In those cases we build on FastAPI or Django and say so during discovery. Compared with a low-code platform, Frappe is open source with no per-user licence, the customisation ceiling is 'anything Python can do', and the application is yours to host, read and hand to another team. Compared with a from-scratch framework, you skip months of building the parts every business application needs and inherit ERPNext's modules whenever accounting, HR or stock enters the picture.

The first design decision is whether the application lives inside ERPNext or beside it. When the domain is one ERPNext already models — accounting, stock, buying, selling, manufacturing, HR — the answer is ERPNext plus a custom app that extends it: Prem Plumbings's multi-warehouse stock, GST handling and payroll posting are extensions and configuration on a full ERPNext. When the domain is a platform of its own — a sales pipeline, a customer-facing assistant, a programme with its own records and roles — the answer is a Frappe application that may install alongside ERPNext for accounting and HR but owns its own doctypes and workflows: the CRM at Land Group and the conversation and escalation layer behind our own site assistant.

Either way the rules are the same, and they exist because the alternative — patching core — is how Frappe systems become un-upgradeable within two years. Fields and property changes go through Customize Form and Property Setters, exported as fixtures in your app. Behaviour goes into hooks — doc_events, overrides, scheduler events — and whitelisted API methods, never into edited core files. Anything larger is its own doctype in your app's module. Data changes ship as patches so an upgrade of a site replays them in order. Every app has tests and runs in CI against the Frappe and ERPNext versions you target. Upgrading from v14 to v15 then means upgrading the platform and re-running your tests — which is what we do on the annual support retainer, not a rescue project.

A Frappe app is built from the data model outward. Discovery produces the doctypes — the nouns of the business, their fields, naming series, links and child tables — and the roles and permission rules that say who may see and do what. Workflows are drawn as state machines with the business before they are configured. From there the work divides into server-side Python (controllers on document events, validation, whitelisted APIs, scheduled jobs), client-side JavaScript (form behaviour, dashboards), portal pages in Vue.js or Frappe UI for external users, reports, print formats and notifications. Every piece lands in a versioned app repository and deploys through bench and CI to staging before production.

• Data model — doctypes, child tables, naming series, links, indexes; role and field-level permissions; permission query conditions for row-level access
• Workflows — states, transitions and the roles allowed to make them; notifications and escalations; assignment rules
• Server side — Python controllers on validate / on_submit / on_cancel, whitelisted REST methods, background and scheduled jobs on Redis Queue
• Client side — form scripts, list and dashboard views, number cards and charts; Vue.js or Frappe UI portals for external users
• Reports & documents — query and script reports, government-format exports, print formats, PDF certificates with QR verification
• Integrations — REST and webhooks to HR, GST, payment, SMS, email and device systems; OAuth2 or API-key authentication; retry and audit on every call
• Quality & delivery — unit and integration tests, fixtures, patches, CI on GitHub Actions, bench deployment to staging and production with backups and restore drills

ATS Global Techsoft — our own business — runs Frappe HRMS and ERPNext accounting on one database, extended with the application behind the assistant on this site: it answers from a context built out of the site's own service and case-study data, applies a request guard before any model call, knows business hours, writes every conversation back into Frappe as a document, and escalates to a human with the thread attached. The pattern: the framework as a record store for something customer-facing, so the conversation and the invoice live in the same system.

Land Group runs Frappe HRMS and a Frappe CRM on one platform: lead capture, ownership and assignment, pipeline stages and follow-up activity beside onboarding, attendance, leave workflows and payroll. Because both are Frappe applications on one database, a salesperson is one record rather than two, dashboards span people and pipeline without an export, and field-level permissions keep salary data and pipeline data in front of different audiences. The pattern: two domains, one database, one permission model — and no synchronisation job to fail.

Prem Plumbings moved off spreadsheets onto ERPNext with Frappe HRMS beside it: chart of accounts, purchase and sales cycles, multi-warehouse stock with reorder levels, GST-compliant invoicing and returns, and payroll posting straight into the ledger instead of being journalled across at month end. Masters and opening balances were migrated rather than re-keyed, and the rollout was staged module by module so the business kept trading. The pattern: ERPNext for the common modules, extensions for the parts the business does differently, and a migration that decides whether anyone trusts the system in week one. Zara Interiors runs Frappe HRMS for a workforce that works on site rather than at a desk — onboarding with documents on the employee record, attendance and shift capture, leave policies with approval workflows, payroll with statutory deductions, and self-service so the record is created as a by-product of the work. The pattern: configuration on standard doctypes wherever the framework already models the domain, so an HR policy change is a setting rather than a release.

Frappe applications scale further than their reputation suggests when they are built with the database in mind. That means indexes chosen from real query plans rather than guessed, list views and reports that filter server-side, heavy work moved to background jobs on Redis Queue, caching for reference data and permission checks, and permission query conditions rather than post-filtering so a user only ever loads the rows they may see. Load testing at the expected concurrency — every site submitting on the same afternoon, or a month-end where the whole company is in the system at once — happens before go-live, not after the first complaint.

Security is role-based access down to the field, document-level permission rules, audit trails on every change, rate limiting and API keys or OAuth2 on integrations, encrypted backups with tested restores, and hosting that matches the data's regulator. Field-level control is what makes a shared platform acceptable in the first place: at Land Group salary data and pipeline data sit in the same system but not in front of the same people. Multi-tenancy — many sites on one bench — is used where an organisation runs several companies or programmes with separate data and shared code.

As a guide from our own projects: a focused ERPNext extension — a few custom doctypes, a workflow, print formats and a report — takes one to three weeks and usually ships inside an implementation. A departmental application such as a learning platform, a partner portal or a compliance tracker, with its own doctypes, roles, portal pages, integrations and reports, is four to eight weeks to a first release. A platform application — many roles, external users in the thousands, a customer-facing portal or assistant, statutory reporting — is a product build of four to nine months delivered in releases, with the first release live within the first quarter.

Five things set the cost: the number of doctypes and workflows and how much bespoke logic sits behind them; the portal and dashboard surface, especially for external users on phones; integrations and the maturity of the systems on the other end; data migration from registers, spreadsheets or a previous system; and hosting, security and residency requirements. User count matters little — there is no per-seat licence. Discovery is a fixed fee that produces the data model, workflow drawings and a costed release plan; builds are fixed price per release with change control; support is a monthly retainer that includes the annual Frappe and ERPNext version upgrade.

Our custom Frappe work clusters where a business has a process that no packaged product models well and a budget that a licensed platform would consume. Distributors and manufacturers extending ERPNext for stock, trade compliance or quality, as at Prem Plumbings. Sales-led businesses that want the pipeline and the people on one platform, as at Land Group. Organisations with a workforce that does not sit at a desk, as at Zara Interiors. Companies that want a customer-facing portal or assistant recording into the same system as their accounts, as we run ourselves. Teams that already run Frappe and want an app rescued, upgraded or extended by people who will not patch core.

If your application does not fit Frappe, the discovery phase says so and the same Python team proposes FastAPI or Django instead. The wider practice — collaboration models, industries, hosting and the full list of case studies — is on the Frappe & ERPNext services page.