ERPNext Africa · platform briefing

ERPNext & Frappe: the platform deep dive

What you're actually adopting when you adopt ERPNext — how the open-source model works as a buyer, how the system is built and customised, why it's unusually ready for AI, and how it stacks up against a bespoke build or a legacy licence.

Business briefing · 2026 · companion to the furniture manufacturing briefing and migration playbooks

01 · What you're actually buying

Two pieces, deliberately separate. ERPNext is the ERP application — accounting, stock, manufacturing, buying, selling, HR, projects, assets — the screens your team uses. Frappe Framework is the platform underneath it — the engine that defines how data, permissions, workflows and APIs work. ERPNext is one (large) application built on Frappe; your own extensions become further applications on the same framework, sitting beside ERPNext rather than patched into it.

Licence — ERPNext is GPLv3 and the framework is MIT: free to use, inspect, modify and host, forever. There is no per-user, per-module or per-site licence fee. Ever.
Who's behind it — Frappe Technologies (Mumbai): a profitable product company that has maintained the codebase for over a decade, funds development through its hosting business (Frappe Cloud) and support plans, and publishes its numbers and roadmap in the open.
What you pay for — implementation, hosting (your own server or managed cloud), and a support arrangement. In other words: the work of making it fit, not the right to use it.
What you own — everything. The code runs on your infrastructure if you want; the data sits in a standard MariaDB database you can query, back up and take with you.

02 · Community, repo & updates — how a buyer should read them

With proprietary software you assess the vendor's brochure; with open source you can assess the actual product development, in public. The signals worth checking (and what they say today):

31k+GitHub stars on the ERPNext repo — with 10k+ forks of the codebase

600+contributors credited on the v16 release

v16major release shipped Dec 2025 — ~2× faster, redesigned workspaces, security hardening

Weeklyfix releases on the maintained stable branches, applied when you choose

How updates actually reach you

Stable branches, continuous fixes — each major version has a maintained branch receiving bug and security fixes on a weekly cadence. Applying them is a routine, reversible operation (managed for you on hosted plans).
Major versions every 1–2 years — with migration scripts included. Moving from v15 to v16 is a planned afternoon-to-a-day exercise for a well-kept site, not a re-implementation project sold at implementation prices.
You control the clock — no forced upgrades, no end-of-support ransom. A version stays runnable for as long as you choose to run it.

What "support" means — four layers, not one

Layer	What it gives you
Your implementation partner	First line: knows your configuration, your BOMs, your close calendar. Contracted response times.
The product vendor	Frappe's own support plans and managed hosting — the people who wrote the code, on call if you want them.
The public commons	Full documentation, Frappe School courses, and a very active public forum where a decade of edge cases has already been asked and answered.
The open codebase	The final guarantee: any competent Python team, anywhere, can read, fix and maintain your system. No vendor can hold your ERP hostage — including us.

The question to ask any ERP vendor (including a bespoke developer)"Show me your issue tracker, your release history, and the number of people who committed code last year." ERPNext's answer is a public URL. For most alternatives the honest answer is a small team, a private backlog, and releases when the retainer allows.

03 · The document model — one idea that runs the whole system

Almost everything in ERPNext is a document: an invoice is a document, an item, a customer, a work order, a warehouse — even users, settings and reports. Every kind of document (a DocType) is defined as structured metadata — its fields, its rules, who may see it — rather than hand-written code. That one design decision produces most of what makes the platform likeable:

Everything comes for free, consistently — define a DocType and the platform generates the database table, the entry form, list views and filters, role-based permissions, a full change history, print formats, and a REST API endpoint. New business object, complete tooling, no bespoke development.
Accounting-grade lifecycle — documents that touch the ledger follow draft → submitted → cancelled/amended. Submitted documents are immutable; corrections are amendments with an audit trail. Your auditors already like this.
Extensible in your language — need to track fabric rolls, delivery routes, or warranty claims with your own fields? A "Fabric Roll" DocType is an afternoon's configuration, and it behaves like every other document in the system: same permissions model, same API, same reporting.
One skill, whole system — because every module is made of the same material, a team member who understands documents, lists and reports in one module can navigate all of them. Training compounds instead of fragmenting.

04 · Customising without forking — the dial from clicks to code

The question that kills legacy ERPs is not "can it be customised?" — it's "what do customisations cost you at the next upgrade?" ERPNext's answer is structural: customisations live as data or as separate apps, never as edits to the product's code. The core updates cleanly underneath them. There's a dial, and you use the lowest setting that solves the problem:

Custom fields & formsno code

Add fields, hide fields, reorder screens, set defaults and validations — from the browser, per role. Most "we're special" requirements end here.

Client scriptslow code

Small scripts that shape form behaviour — auto-fill, warnings, conditional fields — the polish that makes screens feel purpose-built.

Server scriptslow code

Python logic stored as configuration and run by the platform on events you choose: validate this before saving ("no Work Order submits without a fabric batch"), do this after submitting ("email the trade customer when dispatch confirms"), on a schedule ("flag stale quotes every Monday"), or as a custom API endpoint. Sandboxed, permission-aware, versioned — and no deployment needed.

Custom appfull code

For genuinely substantial extensions: a proper application in its own repository, installed alongside ERPNext on the same framework. Your intellectual property, cleanly separated, surviving every core upgrade.

Why this matters commerciallyIn legacy ERPs, customisation is a fork — every change deepens the moat between you and the vendor's next version, until "upgrade" means "re-implementation". In ERPNext the fork never happens: we've taken heavily customised sites through major version upgrades as routine maintenance, because the platform is designed for exactly that.

05 · Ready for AI — and not by accident

Every ERP vendor now claims AI. The practical question is architectural: can an AI agent actually operate the system — safely? Four properties decide it, and ERPNext has had them for years, because they fall straight out of the document model:

What an AI agent needs	What ERPNext provides
To discover what exists	The schema is machine-readable metadata — an agent can ask the system what a Work Order is, what fields it has, and how it links to a Sales Order, without a human writing an integration spec.
To act on anything it's allowed to	Every document has a full REST API automatically — read, create, update, submit, report. If the UI can do it, the API can do it. There is no "API edition" surcharge.
To be contained	Agents authenticate like users, with role-based permissions enforced at the document layer. An agent scoped to "read stock, draft purchase orders" can do exactly that and nothing else.
To be accountable	Every change is versioned with author and timestamp. An agent's work is as auditable as an employee's.

This is why a healthy ecosystem of MCP (Model Context Protocol) servers for ERPNext already exists — the open standard that lets AI assistants like Claude connect to business systems as tools, with allowlisted operations and granular permissions. ERPNext took no re-engineering to get there; the API and permission layer were already the right shape.

Not roadmap — current practiceWe run AI agents against live production ERPNext sites today: reporting agents that answer "how did margin move this month and why" from the ledger, and operational agents that read and write documents over MCP using role-scoped credentials. Ask for a demonstration against a demo site — it's more persuasive than any slide.

The contrastProprietary ERPs meter API access by licence tier and hide schemas behind consulting engagements — the exact opposite of what agent-based automation needs. And a bespoke build rarely has a complete API at all, because APIs are the first thing cut when budgets tighten. Openness turns out to be the AI feature.

06 · Against the bespoke build (the one with <5 sites in production)

The tempting pitch: "we'll build exactly what you need." The physics working against it: software is hardened by production exposure. A custom ERP running at a handful of sites has been tested by a handful of month-ends. ERPNext's codebase is exercised daily by tens of thousands of companies — every payroll quirk, VAT edge case and stock-reconciliation bug they ever hit and got fixed is a bug you will never meet.

Dimension	Bespoke build (<5 sites)	ERPNext
Who pays for every fix & feature	You. 100%. Forever.	Shared across the entire user base; you fund only what's unique to you
Bus factor	A 2–5 person shop; key-person risk is existential	600+ release contributors, a product company, and a global partner network
Upgrade path	There isn't one — the build is the version	Versioned releases with migration scripts, on your schedule
Security	Patched when someone notices	Public process, dedicated security releases, thousands of watching eyes
Documentation & training	Tribal knowledge in the developers' heads	Full public manual, Frappe School, a decade of forum answers
Hiring & continuity	Nobody outside the shop knows the system	Python/JavaScript/MariaDB — a global talent pool; any partner can take over
Accounting engine	Rebuilt from scratch — the hardest part to get right, and the costliest to get wrong	A mature double-entry core that thousands of accountants close on monthly

When custom is the right answerSometimes your operating model genuinely is your edge, and no packaged system fits it. Even then, the smart build is a custom Frappe app alongside ERPNext — you build the 10% that makes you different and inherit the ledger, stock engine, permissions and APIs you would otherwise spend the budget rebuilding badly. Bespoke where it earns; commodity where it doesn't.

07 · Against Sage, SysPro and the licensed mid-market

These are real products with real depth — the case against them isn't quality, it's the shape of the cost and the shape of the lock-in:

	Licensed mid-market ERP (Sage, SysPro, Dynamics…)	ERPNext
Cost shape	Per-user, per-module, per-year — plus annual maintenance, plus upgrade projects. Priced in hard currency; the bill grows every time your team does	Zero licence. Implementation, hosting and support — mostly local services. Seat #80 costs what seat #8 did: nothing
Customisation	Proprietary tools and languages; deep customisation deepens upgrade debt and binds you to specialist consultancies	Config-first dial (§04); standard Python/JS; customisations survive upgrades by design
Your data	Proprietary schemas, restricted direct access, per-tier API metering	Your MariaDB, full schema visibility, complete API included
End of life	Version sunsets on the vendor's schedule; staying put becomes unsupported, moving is a paid migration	No sunset can be imposed on you; the code is yours to run
Exit cost	High by construction — it's the business model	Low by construction — which keeps every vendor around you honest, including us

The honest framing for a mid-market manufacturer: a legacy ERP's extra 10% of niche depth is real — the question is whether it's worth multiples of the ten-year cost of ownership. In our experience the licence line alone, redirected, funds the entire ERPNext implementation and the specific configuration that fits your factory better than any generic module — with the migration playbooks covering how to get across safely.

The one-sentence versionBespoke gives you fit without a future; legacy licences give you a future you rent on someone else's terms. ERPNext is the third option: a maintained, massively-tested product you own — fitted to you by configuration, not construction.

Sources

github.com/frappe/erpnext — repository, stars, forks, contributors, release branches · Frappe v16 release (Dec 2025) — performance, security, contributor count · Frappe Framework docs — DocTypes, server scripts, REST API · Frappe success stories · Frappe community forum · Frappe School · ERPNext MCP servers — community implementations on GitHub · SysPro → ERPNext migration playbook (this site)