When to use a CRM platform instead of this

2026-08-18 · edited by Aetha Editorial

Most teams comparing this framework to a CRM platform should take the platform. That is not modesty; it is the conclusion of our own competitor review, and this article is a write-up of that review rather than a rebuttal to it.

The facts below come from one place: docs/strategy/COMPETITOR_MAP.md, researched on August 4, 2026. Treat that date as this article's verifiedOn. Nothing from any other project was installed or run, GitHub figures are that day's rounded numbers, and licence descriptions are factual summaries, not legal advice. Where the review does not carry a fact, this article does not either. We refresh comparison content on a 90-day clock, because a stale comparison describes a product that no longer exists.

Take a platform if you are buying, not building

The review is blunt about the market line: Odoo, EspoCRM and SuiteCRM own the self-host SMB buyer, and this project does not compete for that buyer directly. If your company wants a CRM that a sales team logs into this quarter — with import, search, email, saved views, reporting, an admin panel and someone to call — buy one. Framework boundary update, September 7, 2026: The framework enforces authorization and one tenant per application instance; the deployment supplies authentication. Self-hosted SQLite and dedicated-database PostgreSQL compositions exist, but are not a general production-readiness claim (L-01, L-02). Customer Data Foundation supports bounded JSON imports with preview/apply, per-row receipts and idempotency, deterministic duplicate candidates, and human-governed canonical identity as logical links. It does not provide CSV ingestion, physical merge, complete export/erasure, bulk editing, saved views or global search (L-06). Durable jobs, a transactional outbox and scheduled asks exist for self-hosted applications that explicitly start a worker. Nothing autostarts; a timer opens an ask, never makes a decision, and no managed worker service or recurrence is included (L-04). No hosted CRM or live email/calendar adapter ships.

The same review notes you cannot responsibly put real customer data into this framework yet: there is no export and no erasure path, so a data-subject request cannot be serviced. For a buyer, that single line should end the evaluation.

Take a platform if you want agent features on a working CRM today

The interesting competition is not the legacy suites; it is the platforms converging on agent-friendly language, and the honest reading of the review is that several of them are ahead of us on their chosen axis.

Twenty is the strongest of these — the review names it the top competitive threat. It records an MIT SDK, a create-twenty-app command, git-backed workspace configuration, a CLAUDE.md in the repository, in-product AI agents, and native MCP confirmed for cloud workspaces (self-host parity unverified there, so unverified here). If you want a working open-source CRM platform whose extension story is genuinely code-shaped, and a runtime and AGPL-plus-enterprise-gated licensing shape are acceptable, Twenty is the comparison to run first.

Relaticle ships the most agent-forward incumbent claim in the researched set: a first-party MCP server with 30 tools. Agents operate the CRM; the review's caveat is that they cannot reshape it — customization is runtime configuration inside a fixed app, with solo-maintainer risk recorded alongside. If "agents working inside my CRM this afternoon" is the requirement, that category exists and Relaticle defines it.

Comp AI's CRM inverts our thesis entirely: an autonomous background agent with a work queue, working inside the product. The review credits it with proving demand and with a genuinely novel evidence-and-sandbox design, and records in the same row why it reads as a thesis demo rather than infrastructure — a fixed schema, single tenant, and very few commits behind a large star count. The review's own warning applies to everyone in the category, us included: stars here are marketing-inflected; measure forks, usage and benchmarks instead.

Frappe CRM is the platform to take if admin-led customization is how your organisation works. Its DocType model — the most mature metadata-driven customization in the researched set — generates forms and APIs from metadata in a running system, and it comes with a managed cloud and the ERPNext ecosystem around it.

The narrow case that remains

What none of the researched projects offers — and the review is explicit that this is a statement about the researched set, not proof the market is empty — is a permissively-licensed framework in the Node ecosystem where a coding agent generates a bespoke CRM as reviewable, owned code, with deterministic workflows, human-approval policy, audit and trace as primitives.

That is the case this framework exists for, and it is deliberately small. A module manifest becomes a migration, a service, a REST resource, an SDK method and Admin screens, with no page code. Commercial policy is deterministic code rather than a model's judgement: a renewal at or above the threshold stops and waits for a named human, and a test asserts that an agent cannot make that decision on the human's behalf — the boundary is a property of the system, not a promise in a README. Every mutation leaves an audit event and a step-level trace. The agent surface is deliberately cautious: anything that generates code or destroys state is dry-run unless you pass an explicit apply flag.

Choose this only if all of that describes your problem and you can supply what is missing: authentication, hosting, PostgreSQL, import, export, and the data-governance path real customer records require. The platforms above supply those things because they are products. This is not a product; it is a framework whose output is an application in your repository.

What we refuse to claim

No speed or build-rate comparison appears here, in either direction, because our agent build benchmark is published but has not been run — any number you see quoted for this project is not ours. No feature matrix appears, because the review does not carry one. And this article expires: when the competitor map is re-researched, it gets re-read against the new facts, and rewritten where they moved.

If you read this far and the platform still sounds right, take the platform. The readers we want are the ones for whom it genuinely is not.

What this post does not mean

These pages describe this repository at this commit. None of them implies the framework is deployable, and none of them is a roadmap: nothing that is not merged appears on this site, in any tense.

  • No authentication ships: the framework authenticates nobody. Production Spine v1 (ADR-038) gives the framework verified identity, organizations and memberships, server-authoritative authorization and one tenant per application instance — so tenancy and authorization now exist and are enforced. What does not exist is authentication: no login, password, session or OIDC implementation ships, and a deployment must supply the adapter that verifies the request. Production mode refuses to start without one. In local-development mode an actor header is accepted as an assertion and is not an identity, which is the default developer posture. This is not shared-database multi-tenancy and it is not a readiness claim.
  • Not shared-database tenancy. createAccordoAppAsync can boot one tenant onto dedicated PostgreSQL databases. Shared-database row-level tenancy is not implemented, and this is not a production-readiness claim.
  • Timers exist; a service that runs them for you does not. Durable jobs, a transactional outbox and scheduled asks exist for self-hosted applications that explicitly start a worker. Nothing autostarts; a timer opens an ask, never makes a decision, and no managed worker service or recurrence is included.
  • No email, calendar or marketing integrations. An in-memory notification provider contract exists. MK1 marketing records supplied funnel observations and human-reviewed proposals only; it has no sending, publishing or spending path.
  • The build benchmark has not been run. The protocol is designed and published; no Successful Agent Build Rate exists yet. Any number you see quoted for this project is not ours.
  • Ownership means vendored source: there is no framework dependency to bump. The published create-accordo@0.1.0 scaffolds vendored source; it is the August 19 snapshot, not the current repository feature set. Use a current source checkout for the capabilities described here; upgrades require merging source (L-08). The framework is copied into the project, not installed as a framework library dependency. The accordo npm name is an empty reservation; the @accordo scope is claimed and deliberately empty.

Every claim and every limitation is on one page, and the questions this project refuses to answer are published beside them.

The evidence this post rests on

Claims

  • C-01 Write a module manifest; the agent turns it into a migration, a service, a REST resource, an SDK method and Admin screens — with no page code.

    LimitGenerated CRUD only. The factory does not generate workflows or approvals for a custom object — that is still handwritten (JTBD-06, partially supported).

  • C-03 Commercial policy is deterministic code, not a model's judgement: a renewal at or above the threshold stops and waits for a named human.

    LimitProven for the built-in renewal object and its single value threshold. A general policy engine over arbitrary custom objects does not exist.

  • C-04 The agent cannot approve on the human's behalf. A test asserts the refusal, so the boundary is a property of the system rather than a promise in a README.

    LimitIn local-development mode the actor is asserted, not authenticated: no authentication ships, so an actor header there is not an identity. This holds a boundary against an honest agent, not against an attacker with network access.

  • C-16 Every mutation goes through a module service or a named workflow, and leaves an audit event and a step-level trace behind it.

    LimitAudit records what the process did under an asserted actor. It is not a tamper-evident or externally attestable log, and it is not a compliance control.

  • C-18 The MCP server exposes project context and narrow write tools to a coding agent; anything that generates code or destroys state is dry-run unless you pass an explicit apply flag.

    LimitStdio only, local only. There is no hosted or authenticated MCP endpoint, and the server inherits the local process's authority.

Grounded in

  • docs/strategy/COMPETITOR_MAP.md

Editor of record

  • Aetha Editorial