Frappe CRM, or customization as reviewable code instead of metadata in a running database?

Where Frappe CRM wins

It is a CRM your team can use. The research file this page reads — docs/strategy/COMPETITOR_MAP.md, dated August 4, 2026 — records Frappe CRM as an end-user CRM app on the Frappe low-code framework (Python, MariaDB, Vue) at 3.1k GitHub stars, deployable on Frappe Cloud, Docker or bench, with SMBs and the ERPNext ecosystem as its customer. This framework is none of that: there is no hosted product and no account (L-07), no authentication, tenancy or RBAC (L-01), persistence is local SQLite (L-02), and nothing installs from npm — the bootstrap runs from a checkout, so ownership means copying source and upgrading means merging (L-08). If what you need is a CRM in use this quarter, the comparison ends in Frappe's favour before it starts.

Its customization model is a strength on its own terms. The file calls the DocType metadata model the most mature metadata-driven customization model in open-source CRM: forms and APIs are auto-generated from metadata in a running system, so an administrator shapes the application without writing code. Where the person doing the customizing is an admin rather than a developer with a repository, that is the better fit — and the huge ERPNext adjacency the file records means a company already inside that ecosystem has every reason to stay in it.

Where this is different

The axis is where a customization lives. The research file's criticism of Frappe is precise: configuration lives in the database rather than in the repository, and metadata customizations have a weak git and review story — in its words, the worst possible shape for a coding agent, because there are no diffs, no review and no tests. Here the same act produces source. A module manifest becomes a migration, a service, a REST resource, an SDK method and Admin screens with no page code (C-01); modules then evolve through explicit revisions, a checked-in state file and append-only named migrations, so history is added to rather than rewritten (C-19); and one command reads checked-in source and reports what the application actually is as deterministic JSON (C-14). None of that says the metadata model is wrong. It says the two models are built for different reviewers: an admin in a running system there, a human reading a diff here.

The agent surface. The file records no first-party MCP in Frappe, with the community building third-party bridges, and it reads the demand recorded in frappe#33170 — MCP with permissions and audit — as evidence for the governance thesis this framework is built on. Here MCP is first-class in every project: the server exposes project context and narrow write tools, and anything that generates code or destroys state is dry-run unless an explicit apply flag is passed (C-18), while every mutation leaves an audit event and a step-level trace behind it (C-16). The symmetry should be stated honestly: their gap is a missing first-party agent surface on a working product, and this is a working agent surface on a framework with no product around it.

The stack difference is recorded but not scored. The file describes Python/MariaDB as outside the coding-agent mainstream and Frappe's AI story as entirely third-party. That is the file's characterisation, not a measurement — the benchmark that could turn it into one has not been run, so no build-rate claim appears here in either direction (L-03).

How to choose

Choose Frappe CRM if you want a CRM in use soon rather than a repository to build one in; if customization by an administrator in a running system is how your organisation works; if you are in or near the ERPNext ecosystem; if a managed cloud matters; and if the AGPL app licence fits what you are shipping — the file records the app as AGPL while the underlying framework is MIT.

Choose this framework in the narrow case: the deliverable is a bespoke commercial process that must exist as reviewable code in your repository, written mostly by a coding agent, with approvals, audit and trace as framework primitives — and you can supply authentication, hosting, PostgreSQL, import and export yourself, because none of them is here (L-01, L-02).

If what you actually want is a governed MCP endpoint over a hosted CRM — permissions, audit, an identity behind every call — the honest answer is that neither column has it today: the file records Frappe's MCP as third-party bridges, and the server here is stdio and local only, with no authentication anywhere (L-01).

What this comparison does not cover

No hands-on evaluation. Nothing from Frappe was installed, configured, benchmarked or run in producing this page. Every fact traces to docs/strategy/COMPETITOR_MAP.md, researched on August 4, 2026, and this environment has no network access to re-verify any of it.

No feature matrix. The file does not enumerate Frappe CRM's pipeline, UI, reporting or automation features, so this page says nothing about them, and nothing should be inferred from the omission.

No pricing. The file records that Frappe Cloud exists and carries no price for it, so no cost comparison is possible here.

Licence descriptions are factual summaries of published texts, not legal advice. The AGPL-app, MIT-framework split is the file's summary; questions about share-alike obligations belong with counsel.

When the competitor research is refreshed, this entry must be re-read against it. A dated page is only as good as its date.