What is an ERPNext developer, and how is it different from a consultant?
An ERPNext developer changes what the software does; an ERPNext functional consultant changes how you use what it already does. Both are useful, and many projects need a little of each, but hiring one when you need the other wastes money.
A consultant configures: company settings, chart of accounts, item groups, warehouses, workflows built from the UI, user roles, email alerts. A developer writes code: a new doctype for machine maintenance logs, a hook that blocks a delivery note when the customer is over credit, a script report joining production and scrap, an API endpoint for your dealer app. If the change can be done entirely from ERPNext's settings and customise-form screens, you may not need an ERPNext developer at all.
ERPNext is built on the Frappe framework, so a strong ERPNext developer is really a Frappe developer who also understands accounting, stock and manufacturing flows. Python on the server, JavaScript in the browser, Jinja for print formats and MariaDB underneath are the daily tools.
Hire a consultant when
You need setup, training, process mapping or configuration that ERPNext supports out of the box.
Hire an ERPNext developer when
You need new data structures, custom logic, reports beyond the report builder, print formats, integrations or an upgrade of customised code.
Custom app vs core edits: the one rule an ERPNext developer must follow
Every customisation belongs in a separate Frappe app, never in the erpnext or frappe folders. This is the single most important thing to check when you hire an ERPNext developer, because core edits are silently overwritten or conflict the next time the bench updates.
A custom app is created with bench, lives in its own Git repository, and is installed on your site next to ERPNext. Inside it, the developer puts new doctypes, Python controllers, JavaScript for forms, reports, print formats and a hooks.py file that tells Frappe when to run the custom code. Frappe's hooks documentation describes doc_events for running code on any doctype's save, submit or cancel, and doctype_js for extending standard form scripts, which merge with the originals instead of replacing them.
Customisations made through the UI, such as custom fields and property setters, should be exported into the app as fixtures. Frappe's docs describe fixtures as records synced from JSON files when the site is installed or updated, created with bench export-fixtures. That way a fresh staging site gets exactly the same fields as production, and nothing depends on someone remembering which box they ticked.
- One custom app per business, in your Git repository
- Custom fields and property setters exported as fixtures
- Logic attached through hooks, not by editing standard controllers
- No files changed inside apps/erpnext or apps/frappe
Server scripts and client scripts: when are they enough?
Scripts saved from the ERPNext UI are fine for small, low-risk rules, and a poor home for anything important. They are quick to write, but they live in the database rather than in version control, so reviews, testing and moving them between sites are harder.
Client scripts run in the browser: hide a field, fetch a value, warn when a discount is too high. Server scripts run Python on the server for document events or small API methods. Frappe's documentation notes that server scripts are disabled by default to improve security on shared benches, can be enabled with bench set-config -g server_script_enabled true, use RestrictedPython so only safe methods are available, and are not allowed on Frappe Cloud's public shared benches, only on private benches.
Our rule of thumb as ERPNext developers: a validation of a few lines can stay a script if you want to edit it yourself. Anything that posts accounting entries, talks to an outside API, or will grow over time goes into the custom app with tests. When we take over a system, we often move a dozen scattered scripts into the app so they are versioned in one place.
Designing custom doctypes that will not hurt you later
A doctype is a table plus its form, list view, permissions and API in one definition. Good doctype design is mostly about deciding what is a master, what is a transaction and what is a child table, before any field is added.
Say you need to log machine breakdowns. A careless design adds forty fields to one doctype. A better one has a Machine master linked to an Asset, a Breakdown transaction that is submittable, a child table for spare parts consumed that creates a Stock Entry on submit, and naming series your maintenance head can read aloud. Permissions follow roles you already have, and the list view shows only what supervisors scan every morning.
An experienced ERPNext developer also asks what should not be a new doctype. If ERPNext already has Maintenance Visit, Quality Inspection or Job Card, extending those with custom fields is usually cheaper and upgrade-safer than cloning them.
- Reuse standard doctypes before inventing new ones
- Keep masters, transactions and child tables separate
- Make documents submittable when they post stock or accounts
- Name series and titles people can say on the phone
- Give permissions by role, never by named user
Reports: report builder, query report or script report?
Use the simplest report type that answers the question. ERPNext gives you three levels, and ERPNext developers are needed only for the last two.
The report builder lets users pick columns and filters on a single doctype and save the view; no developer needed. A query report is a SQL query with filters, good for joins such as sales by territory and item group. A script report is Python that can compute, pivot and chart data, for example production yield per shift with scrap percentages and trend lines, or a receivables ageing that respects your own credit terms. Script reports also handle permissions properly, which matters when branch managers should see only their branch.
Heavy reports need care on large databases. We check indexes, avoid loading whole tables into Python, and test with a copy of your real data rather than a demo company with fifty invoices. If the answer is a management dashboard outside ERPNext, our dashboard developer page covers that route.
Print formats are Jinja templates that turn a document into a PDF, and they are where customers see your ERP. An ERPNext developer builds them when the drag-and-drop print format builder cannot produce the layout you need.
Typical requests we handle: tax invoices with an HSN-wise tax summary, amount in words in Indian numbering, bank details and the e-invoice QR code; delivery challans without prices; job cards for the shop floor with barcodes; item labels sized for a thermal printer; and letterheads that switch by company when you run two GSTINs. We keep CSS simple because the PDF engine is not a full browser, and we test page breaks with a forty-line invoice, not just a two-line one.
Print formats belong in the custom app too, so that a new site or an upgrade carries them automatically.
ERPNext API integrations: WhatsApp, e-invoice, website and apps
ERPNext is easy to integrate because every doctype gets a REST endpoint automatically. Frappe's REST documentation describes resource paths under /api/resource for listing, reading, creating, updating and deleting any doctype, whitelisted Python methods under /api/method, and token authentication where the Authorization header carries the API key and secret joined by a colon.
The integrations we are asked for most, as ERPNext developers in India, are these. WhatsApp: a hook on Sales Invoice submit sends the PDF and a payment link through the WhatsApp Business Platform using an approved template, and delivery status is written back. Website or marketplace orders: incoming orders become Sales Orders with the right price list and warehouse. Mobile apps: a Flutter app for salespeople reads stock and creates orders through the API with a restricted API user. Banks: payment files generated from Payment Entries.
For GST, we prefer the open-source India Compliance app, maintained by Resilient Tech under GPLv3. Its documentation lists e-invoice and e-way bill integration, GSTR-1 automation, purchase reconciliation against GSTR-2A/2B and GSTIN validation, and notes that some API-based features need an India Compliance account with associated costs. Read more on WhatsApp Business API integration.
- Create a dedicated API user per integration with only the roles it needs
- Never reuse the Administrator's keys
- Log every inbound and outbound call with the document name
- Queue outbound calls in background jobs so saving a form stays fast
How does an ERPNext developer handle version upgrades?
By treating every upgrade as a small project with a staging copy, a checklist and a rollback plan. The ERPNext repository now presents v16 as the current version, and many Indian businesses are still running v14 or v15 with customisations of mixed quality.
The work starts with an audit: list every custom app, every fixture, every server and client script, every core file that was edited, and every override. Frappe's hooks documentation notes that override_doctype_class replaces a standard doctype's Python class completely and can conflict when several apps do it, and recommends extend_doctype_class instead from v16. Overrides are usually where upgrades break.
Then we clone production to a staging site, run the upgrade there, fix patches and deprecated calls in the custom app, and ask two or three of your users to run their daily tasks for a few days. Only after that do we schedule a production window, with a fresh backup and a tested restore. Jumping several major versions is done one version at a time.
- Audit custom apps, scripts, fixtures and any core edits
- Move core edits into the custom app first
- Upgrade a staging clone, never production directly
- User acceptance on staging with real daily tasks
- Backup, restore test, then the production window
Skills to test before you hire an ERPNext developer
Test for Frappe habits, not just Python. Plenty of good Python developers write ERPNext code that works today and breaks next quarter because they do not know the framework's conventions.
Ask a candidate to explain, in their own words: where they would put a custom field and how it reaches another site; the difference between validate, before_submit and on_submit; why frappe.db.sql with string formatting is dangerous; how they would run a slow job in the background; and how they would test an upgrade. Then give a small paid task, for example a custom field on Sales Order that must be copied to Delivery Note and printed on the challan, delivered as a pull request to a custom app.
Look at the pull request, not just the result. You want a fixture for the field, a hook rather than a core edit, a clean commit history and a short README. That tells you more about an ERPNext developer than any certificate.
- Frappe doctypes, hooks, fixtures and permissions
- Python on the server, JavaScript form scripts in the browser
- Jinja print formats and SQL for query reports
- Accounting, stock and manufacturing flows in ERPNext
- Bench, Git, backups and staging discipline
ERPNext developer rates in India: hourly, monthly or per project?
Per project is safest for defined work; a monthly retainer suits a steady trickle of small changes; hourly suits only very short diagnostic work. Rates quoted by ERPNext developers vary widely across freelancers, marketplaces and Frappe partners, and the spread comes from experience with upgrades and accounting, not from typing speed.
With us, a defined integration starts at ₹40,000, and a custom app with several doctypes and reports starts at ₹60,000. After the free two months, ongoing care starts at ₹8,000/mo a month. Each quote is itemised so you can see what a report or a print format costs on its own and drop lines if the budget is tight.
Be wary of an hourly quote with no estimate, and of a very low fixed-looking figure for a vague brief. The first leaves you without a ceiling; the second usually means the work will be done quickly inside core files. See our ERP software development cost page for how ERP budgets break down more broadly.
Does hosting change what an ERPNext developer can do?
Yes. Where ERPNext runs decides whether custom apps and server scripts are allowed at all, and who can reach the server during an emergency.
On Frappe Cloud, custom apps are installed on a private bench, and Frappe's own docs note that server scripts are not allowed on public shared benches. On your own VPS or cloud server you have full control, and also full responsibility for backups, security updates and monitoring. Some businesses still run ERPNext on an office server, which works until the power or the internet line fails.
Whatever you choose, the developer should have a staging site that mirrors production, deploy from Git rather than by copying files, and keep backups off the server. Our cloud hosting setup page covers the server side.
Red flags when hiring an ERPNext developer
The biggest red flag is code in core. Ask directly: “Will any file inside the erpnext or frappe apps be changed?” The only acceptable answer is no.
Other warning signs: the developer wants to work directly on your live site with no staging; the custom app lives in their Git account, not yours; there is no fixture export, so custom fields exist only in production; heavy logic sits in dozens of UI server scripts; they cannot explain how an upgrade would be tested; or the quote says nothing about who fixes bugs after delivery.
If you have inherited a system with these problems, it is fixable. We have written up what to do when a developer leaves midway, and the first step is always the same: back up, audit, and move customisations into an app you own.
- Edits inside the erpnext or frappe apps
- No staging site; changes made on production
- Repository owned by the developer
- Custom fields not exported as fixtures
- No upgrade plan or rollback plan
Who owns the code an ERPNext developer writes?
You should, completely. ERPNext itself is licensed under GPLv3, according to its GitHub repository, and your custom app is your code in your repository, installed on your server or Frappe Cloud account.
We create the repository under your GitHub or GitLab organisation and give you admin rights from the first commit. API keys for integrations are created for dedicated users in your ERPNext and stored in your site configuration. At the end you receive the repository, a README describing each doctype, hook and report, a runbook for deploying and restoring, and a recorded walkthrough. If you bring in another ERPNext developer later, they can pick it up without calling us.
How to brief an ERPNext developer so the quote is accurate
Describe the business event, not the screen. “When a customer is over their credit limit, the delivery note should not submit unless the sales head approves” is a brief a developer can price. “Add a button” is not.
A good brief for an ERPNext developer includes your ERPNext and Frappe versions (from the About dialog), where it is hosted, the list of installed apps, two or three example documents with names, screenshots of the current form, and who approves the finished work. If you are replacing a spreadsheet, send the spreadsheet. If an integration is involved, send the other system's API documentation or a sample payload.
- ERPNext and Frappe versions, and hosting
- Installed apps, including any custom apps
- The business event and the rule, in one sentence each
- Example documents and screenshots
- Sample payloads for any outside system
- Who signs off, and by when
Worked example: a hypothetical ERPNext developer brief for a fastener maker
Suppose a fastener manufacturer near Rajkot runs ERPNext v15 on its own server. A previous developer edited two core files to add a heat-number field, the dispatch team wants test certificates printed with each invoice, and dealers keep calling to ask whether stock is available.
The scope we would propose: first, move the heat-number change into a new custom app with fixtures and a hook, then remove the core edits. Second, a Test Certificate doctype linked to Batch and a print format that attaches to the tax invoice. Third, a small dealer stock lookup through the REST API with a read-only API user, shown on WhatsApp or a simple web page. Fourth, a staged upgrade to v16 once the core is clean.
Integration and certificate work would start at ₹40,000; if the dealer portal grows into ordering and payments, it becomes a custom app from ₹60,000. This is an illustration of how we scope, not a real client or a measured outcome.
Hiring an ERPNext developer anywhere in India
ERPNext development is done remotely by nature: code goes to Git, deploys go to a server, and reviews happen on a shared screen. Businesses in Rajkot and Ahmedabad often need manufacturing and batch-tracking customisations; Hyderabad and Chennai firms ask for integrations with pharma and auto-component customers; distributors in Vadodara and Raipur want dealer portals; and service businesses in Noida and Chandigarh mostly need project billing and reports.
We talk in English or Hindi on WhatsApp and Google Meet, every day of the week. We do not visit factories; if a shop-floor process is unclear, a short video from your supervisor usually explains more than a site visit would.
ERPNext developer hiring checklist
Run through this before you sign with any ERPNext developer, including us. It takes ten minutes and prevents most of the expensive mistakes we are later asked to fix.
- They promise no core edits and show you a custom app structure
- The repository is created in your organisation's account
- A staging site exists or is part of the quote
- Custom fields travel as fixtures
- Integrations use dedicated API users with limited roles
- The upgrade approach is written down
- Bugs after delivery are covered for a stated period
- Handover includes README, runbook and a walkthrough
If you are also comparing ERPNext with other platforms, our Odoo developer page uses a similar checklist for Odoo modules.