Ask most CTOs what Frappe is and they will say "the thing ERPNext runs on". That is true, and it undersells it. ERPNext is one application on the Frappe Framework. Frappe itself is a full-stack web framework with a metadata-driven data model, a permission system, a REST and RPC layer, background jobs and an admin interface, all generated from the same definitions.
That combination matters when you are building a product, not an ERP. A good share of what we deliver on Frappe has no accounting module in sight: a court management platform, a device-pass backend, a certification platform and a 3D product configurator. This piece explains what the framework gives you, how those four platforms used it, and where we would not choose it.
What you get from one DocType
In Frappe, the unit of design is the DocType. You describe an entity once (its fields, types, links to other entities, child tables, naming rule and permissions) and the framework produces:
- a database table, with migrations handled when the definition changes
- a list view, a form and a report view in the admin interface (Desk)
- REST endpoints for create, read, update, delete and filtered lists, authenticated by session or API key
- permission checks on every one of those paths, by role, by document owner and by user-level restrictions
- a version history of every change, and comments and attachments on every record
- hooks for validation and side effects at each stage of the document's life
Logic that does not fit a CRUD shape goes into whitelisted Python methods, which the framework exposes as RPC calls with the same authentication and permission model. Slow or scheduled work goes onto background queues backed by Redis, with a scheduler for periodic jobs. Real-time updates go over a socket connection. Print formats, email, file storage, translations and multi-site tenancy (one codebase, a database per tenant) are already there.
The practical effect: the first month of a new product is spent on the problem, not on authentication, admin screens and audit trails. In our experience that is where the time goes on a greenfield build.
Four platforms, none of them an ERP
A court management platform for AdComp Systems
SmartCourt is AdComp Systems' court management product, and we are the engineering team that designed and built it. It replaced QuickCourt, a legacy application courts had used for many years. It is a fully custom application on the Frappe Framework with no standard ERP modules: charge entry and traffic citations, case and docket management, record classification for traffic, civil, criminal and juvenile matters, hearings, payments and payment plans, cash bonds, a case jacket that shows everything about a defendant in one view, centralised printing and XML state reporting.
Two parts of that build lean directly on the framework. Payments arrive from AdComp's web, mobile, IVR, kiosk and POS channels and are synchronised into SmartCourt through APIs, with component-wise disbursement tracking. And the users are court managers, clerks and marshals, so role-based access had to be tight and simple. It took about six months from design to first deployment and now holds more than 35,000 cases.
A device-pass backend for a security services company
A security services company manages passes for a fleet of mobile devices enrolled in Samsung Knox Manage, an enterprise mobility management (EMM) system. Pass decisions were split between the EMM and spreadsheets, and registrations that did not match a known device had nowhere to go.
The architecture is the interesting part. The EMM supplies data only. Frappe owns every pass decision. A React admin consumes the Frappe REST API. The data model is six DocTypes (devices, installed apps, SIMs, an activity log, unmatched registrations and settings), and a pass moves through five states: Pending Activation, Active, Temporary, Inactive and Expired. Barcodes are signed with HMAC-SHA256 so a pass cannot be forged by editing it.
The unmatched-registrations DocType is the detail we would point a CTO at. A record that fails to match is not an error in a log; it is a document with an owner, a status and a history, because creating that is cheap in Frappe.
A certification platform for a national certification body
A national certification body enrols learners, runs proctored examinations, issues certificates and bills institutions rather than learners. The design uses Frappe as a headless backend with a React front end. Proctoring comes through a JavaScript SDK, payments through Razorpay, and the body's existing ERPNext keeps doing the invoicing. The bill-to party is decoupled from the learner, Aadhaar is not required, and DigiLocker is optional. The business requirements document alone runs to 164 requirements across 12 modules and 55 screens, which gives a sense of how much product sits on top of the framework.
A 3D configurator for Sub Zero
Sub Zero Insulation Technologies makes insulated reefer boxes. Configuring one used to mean e-mails, drawings and a sales engineer for every variant. Dealers now use a self-service portal: a React front end with a real-time 3D parametric engine on a Frappe backend, in five languages including right-to-left Arabic, with quotations flowing into ERPNext v16.
Here the ERP is downstream. The configurator is the product; ERPNext receives the result.
The front end is a separate decision
Frappe gives you Desk for free, and for back-office users it is often the right answer: staff who process records all day want dense lists, filters and keyboard shortcuts, not a marketing-grade interface. The other side of the line is just as common: the security company's operators use a React admin, and the certification body's learners and Sub Zero's dealers get their own React front ends.
Our rule of thumb is to choose by who logs in:
| Who logs in | What we usually build |
|---|---|
| Internal staff processing records | Desk, with custom forms, list settings and workspaces |
| Partners, dealers, vendors | A portal in React or Vue on the REST and RPC API |
| Learners, customers, the public | A dedicated front end, designed as a product |
| Other systems | The REST API, webhooks and scheduled sync jobs |
Whatever the front end, the rules stay on the server. Permissions, state changes and validation belong in the backend, so a second front end (a mobile app, a partner integration) cannot bypass them. That is the point of "Frappe owns every pass decision" in the device-pass case.
Where we would not choose Frappe
The framework is not the answer to everything, and saying so is part of a sound architecture review.
- Very high write throughput. Every document save runs validation, hooks and version tracking. That is what you want for business records and too much for millions of telemetry events an hour. Put those in a store built for it and send Frappe the events that need a decision.
- A consumer app at internet scale. Frappe can serve a public site, but a product whose main load is anonymous traffic is better on a stack designed for that, with Frappe behind it as the system of record if it fits.
- A team that will fight the conventions. Frappe is opinionated about naming, permissions and how code is organised. A team that wants to replace those patterns gets the cost of the framework without its benefits.
- Heavy graph or analytical workloads. Frappe sits on a relational database (MariaDB first, with PostgreSQL support). Analytics at volume belongs in a warehouse fed from it.
What we tell a CTO who is evaluating it
- Model the domain first. List the entities, their states and who may change them. If most of them are records with a lifecycle and an owner, Frappe will save you real time.
- Decide what the backend owns. Write down which system makes each decision. In the device-pass build that was one line, and it shaped everything else.
- Keep your code in its own app. Your product should be an app installed on the framework, in your repository, never a patch to the framework itself. We explain why in our piece on custom apps and upgrades.
- Treat the API as a contract. Version the whitelisted methods your front end calls, and test them, because a React or mobile client cannot follow a silent change.
- Plan the ERP connection early. If the product produces quotes, invoices or orders, decide whether ERPNext lives on the same site, on another site, or not at all. The certification body kept its existing ERPNext for invoicing; Sub Zero sends quotations into ERPNext v16.
If this is your situation
If you are deciding how to build a portal, a platform or a product and want an engineering view on whether Frappe fits, read how we approach platforms and portals and custom product development, or, if you are building a startup, how we work with startups. Then tell us what you are building and an engineer will reply with questions.
