The 80% nobody should build twice

Ask a team what their internal system does and you will hear about the work: the approval chain, the pricing rules, the way a job is scheduled and closed. Ask how long it took to build and most of the time went somewhere else entirely — logging in, deciding who may see what, wiring an API, making a PDF, running a nightly job, and working out how to restore the database after someone dropped a table.

That other work is not optional. Every business application needs it. Almost none of it is your business.

Frappe is a framework built on the observation that this eighty percent is the same everywhere, so it should be written once.

definition per entity — the DocType — which produces the table, the form, the list view, the API and the permissions together

things you get from that one definition before writing any application code

forks of the core required: custom behaviour lives in your own app, so upgrades stay possible

One definition, five products

The core idea is small and it compounds. In Frappe you describe an entity once — its fields, its types, its links to other entities — and the framework generates the rest: the database table, the form for editing it, the list view for finding it, a REST endpoint for reading and writing it, and the permission rules that decide who may do which of those things.

Add a field and it appears in all five places. Change a validation and it applies to the form, the API and any background job that touches the record, because they all run through the same layer.

Describe
Fields, types and links, in one DocType definition — no separate migration file, no duplicate form schema.
Generated
Table, form, list view and REST endpoint appear together, consistent by construction.
Governed
Roles and permissions attach to the same definition, so the API cannot bypass what the form enforces.
Extended
Custom logic goes in your own app with hooks — the core stays untouched, so upgrades remain a command.

The compression. The savings are not in typing less; they are in never letting the five views of one entity drift apart.

What comes in the box

Around that core, Frappe ships the unglamorous machinery every deployment needs: users and roles, a REST and RPC API, background job queues, real-time updates over websockets, email, file storage, print formats and PDF generation, scripted reports, workflows, translations, and a command line — bench — that installs, updates, backs up and restores a site.

ERPNext, the accounting and operations suite, is built on the same framework, as are the CRM, Helpdesk, HRMS and LMS products. That matters for a simple reason: if your application needs accounting, stock, projects or support, you are not integrating with a third-party system over HTTP and reconciling two data models. You are adding a DocType beside the ones that already exist.

One definition, five products

Where the money actually goes

A build on a general-purpose stack spends its first weeks on scaffolding: authentication, session handling, an ORM, an admin interface, a permission model, a migration tool, an API layer, a job runner, a PDF library, and the deploy script that ties them together. Every one of those is a place to introduce a security bug, and every one must be maintained for as long as the application lives.

On Frappe, that list is configuration. The budget moves to the part the business actually cares about — the pricing rule, the approval chain, the scheduling logic — which is also the part that is hardest to outsource and the only part a competitor cannot copy.

Undifferentiated work80%

auth, permissions, API, jobs, reports, deploy, backups

Your actual business logic20%

the rules nobody else has

ABN Asia's rule of thumb from Frappe projects, not a measurement. The point is which half you are paying for.

What this means for a small team

The usual objection is that a framework is a commitment. It is — and the commitment is smaller than the alternative, because the alternative is committing to a bespoke stack that only the person who built it understands.

With Frappe, a small team can run a system that a much larger team would otherwise need: one server, one database, one deploy command, one backup, and an upgrade path that does not require re-testing the login screen. When the application outgrows the server, the same code moves; when the requirements change, the change lands in a DocType rather than in five places.

Where ABN Asia comes in

We build and maintain Frappe applications: new applications for a process that has outgrown spreadsheets, extensions to ERPNext that fit how a business actually works, migrations off legacy tools, and the unglamorous part — hosting, upgrades, backups, monitoring and the small changes that arrive every month.

The work we do not do is rebuild the eighty percent. It already exists, it is tested by a large community, and it is better than what most teams write in their first month under deadline.

If you have a process running on spreadsheets and email, the useful first conversation is not about technology. It is about which of those rules are actually rules, and which are habits nobody has questioned.

Source: ABN Asia's own Frappe engagements, 2026. The effort split above is a rule of thumb from that work, not a measured statistic.

Contact: [email protected]