ERPNext custom app development
ERPNext Custom App Development: When to Use Frappe Instead of Core Customisation
Learn when UK businesses should use Frappe custom app development instead of ERPNext core customisation, including custom fields, scripts, workflows, reports, integrations, upgrades and long-term maintainability.
ERPNext is popular because it is flexible. A business can add custom fields, workflows, reports, dashboards and scripts without rebuilding the entire ERP. But the wrong customisation approach can create long-term problems—scattered scripts, upgrade risk and undocumented changes.
Use ERPNext core customisation for small, site-specific changes. Use Frappe custom app development when the requirement is complex, reusable, business-critical, integration-heavy or needs long-term maintainability.
Build a Frappe custom app for new modules, custom DocTypes, complex workflows, API integrations, scheduled jobs and version-controlled deployment. Use core customisation for simple fields, labels, basic workflows, print formats and small Client Scripts.
1. What Is ERPNext Core Customisation?
Core customisation uses built-in tools: Customize Form, Custom Fields, Property Setters, Client Scripts, Server Scripts, Workflows, Print Formats, Custom Reports, Dashboards and Role Permissions. Examples: add Customer PO Number to Sales Invoice, PO approval above £1,000, branded invoice print format.
2. What Is a Frappe Custom App?
A Frappe custom app is a separate application built on the Frappe Framework and installed alongside ERPNext. It can contain custom DocTypes, Python controllers, hooks, API methods, background jobs, fixtures, patches, tests and permissions—keeping business logic separate from ERPNext core code.
3. Core Customisation vs Custom App: Practical Difference
| Requirement | Core Customisation | Frappe Custom App |
|---|---|---|
| Add simple field / workflow | Good fit | Usually unnecessary |
| Complex workflow / new module | Limited | Strong fit |
| API integrations / scheduled jobs | Limited | Strong fit |
| Version control / multi-site deploy | Weak unless exported | Strong |
| Long-term maintainability | Risky if scattered | Better |
4. Why This Decision Matters
- Nobody knows which Custom Fields are still used
- Client Scripts conflict; Server Scripts hard to debug
- Dev, test and production sites behave differently
- Customisations not in Git; upgrades become risky
The better question is not “Can ERPNext do this?” but “Where should this customisation live so it remains maintainable after go-live?”
5. When Core ERPNext Customisation Is Enough
- Adding fields, hiding unused fields, renaming labels
- Simple workflows, notifications and Report Builder reports
- Print format changes and basic form calculations
- Example: Customer PO Number field—Custom Field is enough unless complex validation needed
6. When You Should Use a Frappe Custom App
New business logic, DocTypes and integrations
- Rental booking, recruitment payments, field service scheduling, retention workflow
- Custom DocTypes: Service Job, Rental Contract, Variation Order
- Shopify, HMRC, courier, payroll, 3PL integrations with logs and retry logic
- Server-side rules that must not be bypassed via API or import
7. Why Not Modify ERPNext Core Directly?
Avoid editing ERPNext core files directly. Upgrades become difficult, patches may fail, and custom logic mixes with product logic. Use configuration, fixtures, custom apps or supported hooks instead. Editing core should be a last resort.
8. Custom Fields: Core Customisation or App?
Simple site-specific fields use Customize Form. Export as fixtures in a custom app when the field supports business-critical logic, must exist across sites, is used by integrations or affects permissions and workflows.
9. Client Scripts: When They Are Enough
Client Scripts are good for auto-filling fields, showing/hiding fields, filters and UX improvements. They should not enforce business-critical rules alone—client-side logic can be bypassed through API, imports or server processes.
10. Server Scripts: Useful, But Not Always Enough
Server Scripts work for simple validation and notifications on one site. They become risky for complex logic—harder to version, test, debug and deploy across sites. Large workflows need proper app development.
11. Workflows: Core or Custom App?
Standard Workflows handle PO, quotation and expense approvals. A custom app is needed when workflow depends on complex calculations, creates multiple linked documents, uses external APIs or triggers background jobs.
12. Reports: Custom Report or Custom App?
Report Builder and Query Reports suffice for simple sales, purchase and stock reports. Custom apps help for complex management reports based on custom DocTypes, compliance reporting, multi-site deployment and version-controlled calculations.
13. Integrations Almost Always Need a Custom App
Proper integrations need API credentials, logs, retry logic, scheduled sync, mapping tables, failure alerts and audit trails. Shopify, WooCommerce, HMRC, courier and 3PL integrations belong in a custom app—not scattered scripts.
14. Industry-Specific ERPNext Custom Apps
| Industry | Custom App Examples |
|---|---|
| Recruitment | Candidate payments, visa tracking, commission |
| Equipment rental | Booking, dispatch, damage inspection, deposits |
| Field service | Service job, technician schedule, mobile job sheet |
| Construction | Variation order, retention, application for payment, CIS |
| eCommerce | Channel sync, settlement import, courier integration |
15. Version Control: Why Custom Apps Are Safer
Custom apps stored in Git track who changed what, which site has which version, and which custom fields and reports are included. Without version control, changes exist only on the live site—hard to trace, deploy or roll back.
16. Fixtures: Moving Customisation Between Sites
Fixtures export Custom Fields, Property Setters, Workflows and Print Formats into an app for deployment across development, UAT and production sites—essential for professional ERPNext projects.
17. Hooks: Extending ERPNext Without Editing Core
Hooks connect into Frappe/ERPNext for DocType events, scheduled tasks, permission logic and method overrides. Example: when Sales Invoice is submitted, create commission record; nightly Shopify order sync.
18. Upgrade Safety: Custom App vs Core Changes
Custom Fields and Workflows can survive upgrades if built correctly. Custom apps survive upgrades when they follow framework conventions. Direct core modifications are risky. App-based development gives better separation and testability.
19. When Not to Build a Custom App
- A simple Custom Field or standard Workflow is enough
- Requirement is temporary or not approved by the business
- Users have not tested the standard process
- The problem is training, not software
20. Customisation Decision Framework
- Available in standard ERPNext? → Use standard features
- Small site-specific change? → Custom Fields or scripts carefully
- Business-critical, multi-site, integration or version control need? → Custom app
- Will it make upgrades harder? → Design properly in a custom app
21. Practical Examples
| Requirement | Best Approach |
|---|---|
| Add Delivery Route field to Sales Order | Custom Field |
| Delivery route planning with driver tracking | Frappe custom app |
| Candidate passport number on Customer | Custom Field / fixture |
| Full recruitment candidate management | Frappe custom app |
| Shopify order sync | Custom app or integration app |
| PO approval above £1,000 | Standard Workflow |
22. Custom App Development Process
- Discovery and fit-gap analysis
- Functional specification and technical design
- Development in dev environment—not production
- Testing, UAT and controlled deployment
- Post-go-live support and monitoring
23. Custom App Testing Checklist
Test installation on clean site, patches, fixtures, DocTypes, permissions, workflows, reports, API endpoints, scheduled jobs, error handling, upgrade behaviour, performance and security.
24. Deployment Checklist for Frappe Custom Apps
- Code committed to Git; fixtures exported; patches tested
- Backup taken; bench migrate completed
- Smoke testing and log review after production deployment
25. Custom App Governance
Governance rules: no direct core edits without approval; major customisations through fit-gap review; all app code in Git; test in staging before production; all upgrades include custom app testing; all changes have business sign-off.
26. Common ERPNext Custom App Mistakes
- Editing ERPNext core directly
- Building custom app before testing standard ERPNext
- Using Client Scripts for critical business rules
- Not using Git or exporting fixtures
- Not testing on clean site or planning permissions
- Over-customising simple workflows without support budget
27. Cost Considerations
Custom app costs include discovery, design, development, testing, UAT, deployment, documentation and upgrade testing. Before approving, ask what business problem it solves, whether standard ERPNext handles 80% of the need, and who will maintain it.
28. Why Work With Talpha Solutions?
Talpha Solutions helps UK businesses with ERPNext customisation review and Frappe custom app development—fit-gap analysis, custom DocTypes, workflows, reports, API integrations, fixtures, Git-based development, UAT, go-live and upgrade planning. We do not recommend a custom app for every small change.
Final Advice
Use standard ERPNext wherever possible. Use core customisation for small site-specific changes. Use Frappe custom apps for complex, reusable, integration-heavy requirements. Avoid direct core edits. The best implementations customise carefully, document properly and maintain responsibly.
Call to Action
Planning ERPNext customisation or Frappe custom app development? Book a free ERPNext customisation review with Talpha Solutions. We will review your requirement, check whether standard ERPNext can support it, identify whether a custom app is needed, and recommend the safest development approach.
FAQ
Frequentlyasked questions
Answers to common evaluation questions.
ERPNext custom app development means building a separate Frappe app that extends ERPNext with custom DocTypes, workflows, reports, integrations, scripts, permissions and business logic.
ERPNext customisation usually uses built-in tools such as Custom Fields, Workflows, Print Formats, Client Scripts and Reports. A custom app is a separate Frappe application with version-controlled code, DocTypes, hooks, fixtures and business logic.
Use a Frappe custom app when the requirement is complex, business-critical, reusable across sites, integration-heavy, server-side, or needs version control, testing and long-term maintainability.
Core customisation is enough for simple changes such as adding fields, changing labels, creating simple workflows, adjusting print formats, adding basic reports or improving form behaviour with small scripts.
Usually no. Directly editing ERPNext core files can make upgrades difficult and increase maintenance risk. Custom logic should normally be handled through configuration, fixtures or a separate Frappe custom app.
Client Scripts are useful for form behaviour and user experience, but critical business rules should usually be enforced server-side because client-side logic can be bypassed through imports, APIs or backend processes.
Fixtures allow customisations such as Custom Fields, Property Setters, Workflows and Print Formats to be exported into an app and deployed across development, testing and production sites.
Yes. Integrations usually benefit from a custom app because they need API handling, credentials, logs, retry logic, scheduled jobs, error handling and mapping tables.
A custom app can make upgrades easier because custom code is separated from ERPNext core and can be tested independently. However, all custom apps still need upgrade testing.
The biggest mistake is over-customising too early or editing ERPNext core directly. Businesses should first test standard ERPNext, then use configuration, and only build a custom app when there is a clear business need.