Frappe and ERPNext are not the same thing

People use “Frappe” and “ERPNext” interchangeably. In a hiring conversation that is harmless. In a project plan it causes real problems, because they are two different layers with different skills, risks, and costs.

The short version

Frappe is the open-source framework: the database abstraction, document model, permissions, workflows, reporting, and UI toolkit. It is also the name of the company and the community around it.

ERPNext is one application built on that framework: accounting, selling, buying, stock, manufacturing, projects, HR, and so on.

You can run Frappe without ERPNext. Many teams do, for custom internal tools, portals, and industry apps. ERPNext does not run without Frappe.

ERPNext, CRM, Helpdesk, HRMS, LMS   ← applications
────────────────────────────────────
Frappe framework                     ← metadata, permissions, workflows, UI
────────────────────────────────────
MariaDB / PostgreSQL, Redis, workers ← infrastructure

Why the distinction matters

Skills are not the same

An ERPNext consultant knows the business configuration: chart of accounts, item masters, pricing rules, production planning. A Frappe developer knows the framework: doctypes, controllers, hooks, background jobs, and how to build an app that survives an upgrade.

Most implementations need both. Hiring one person who claims deep expertise in both, with references, is harder than it sounds.

Upgrades behave differently

ERPNext upgrades bring business-logic changes. Your chart of accounts, tax templates, and custom fields may need review. Frappe upgrades bring framework changes that affect custom code: deprecated hooks, changed APIs, migration patches.

If you have heavy customisation, budget for both: application-level regression testing and framework-level code review.

Customisation has a location

A useful rule: put business logic in a custom app, not in the ERPNext codebase. Custom apps sit beside ERPNext and survive upgrades more cleanly. Editing core files feels faster and costs more every year after.

Licensing expectations

Both are open source, but “open source” is not “free to operate”. You still pay for hosting, implementation, migration, support, and internal time. The licence is the cheapest part of the project.

A practical staffing model

For a mid-market ERPNext implementation, a workable team is:

One implementation lead who owns scope, process design, and the client relationship.
One developer for custom apps, integrations, and migration scripts.
One business analyst or super-user lead on the client side, part-time but committed.
Infrastructure support, part-time, for backups, monitoring, and upgrades.

Small projects can combine roles. The mistake is assuming the implementation lead can also carry all the custom development without either scope or quality slipping.

How this changes an estimate

When you compare quotes, ask what each assumes:

Is customisation done in a separate app or by editing core?
Is migration scripted and repeatable, or manual?
What is the upgrade path after go-live?
Who is on call when the scheduler stops at 2am?

Two quotes for “ERPNext implementation” can differ by a factor of three because one is configuration and the other is a software project. The word on the proposal is the same; the work is not.

What to take away

If you are buying an ERP, ask about the application. If you are building on the platform, ask about the framework. If someone blurs the two, ask them to separate the work — and to show you where the custom code lives.