Open source. Not deployable to production. This page states what the tests prove and what is missing — nothing else.

What is a CRM framework?

CRM framework, defined

People ask this as: what is a crm framework, open source crm framework for developers

A CRM framework is source code a development team composes into its own CRM application: the framework supplies the runtime contracts — records, services, workflows, policies — and the team supplies the domain. A CRM product is configured; a CRM framework is programmed, and the resulting application belongs to whoever wrote it rather than to a vendor. Accordo is an open source CRM framework for developers and their coding agents, MIT-licensed with zero third-party runtime dependencies — and nothing about the term makes the result deployable: this one has no authentication, no tenancy, SQLite persistence and no hosted offering.

Where this stops

Read this before the rest of the page. Every line below is a thing this does not do.

  • A CRM framework is not a CRM product. There is nothing to sign up for here — no hosted CRM, no account, no free tier; the output is an application in your repository (L-07).
  • 'Open source CRM framework' describes the licence and the source, not a distribution channel. Nothing installs from npm: the bootstrap scaffolds from a checkout and upgrading means merging (L-08).
  • 'CRM for developers' does not make the result deployable. There is no authentication, tenancy or RBAC, and persistence is local SQLite (L-01, L-02).
  • Zero third-party runtime dependencies is a property of the framework, not of the application you build on it.
  • The definition on this page is not a measured comparison. No benchmark has been run against building from scratch or against any product (L-03).

No authentication, tenancy or RBAC. The server is local-development-only. An actor header is an assertion, not an identity. Do not expose it to a network. Every claim and every limitation is on one page.

The definition, and the line it draws

A CRM framework is a body of source code that a development team builds a customer relationship management application on top of. It provides the mechanics every CRM needs — a way to declare records, persist them, mutate them through services, run multi-step workflows, apply business policy and expose an API — and it deliberately does not provide the finished CRM. The domain (what a lead is, when a discount needs approval, what happens after a deal is won) is the application author's to write.

The line this draws is between configuring and programming. A CRM product — hosted or self-hosted — is configured: custom fields, automation rules, permission sets, all expressed inside the vendor's runtime and only meaningful there. A CRM framework is programmed: the output is an application in the team's own repository, reviewable in a diff and owned outright. 'CRM for developers' can mean either a product with a good API or a framework; the two are different categories, and the test is what you are left with if the vendor disappears — an account export, or a codebase.

'Open source CRM framework' adds a licence to that, not a capability. It says the framework's source may be read, changed and kept under the stated terms. It does not say the result is deployable, secure or complete, and a licence page is not an architecture page.

How Accordo implements the term

Accordo's unit of composition is a module manifest: the author declares a record's fields once, and the framework turns the declaration into a migration, a service, a REST resource, an SDK method and Admin screens, with no page code written by hand (C-01). Business behaviour is not generated — services, workflows and policies stay explicit, reviewable source, which is the property that makes the framework usable by a coding agent under human review.

Domains larger than one record live in packages. A customer-authored domain package attaches with one static import and detaches with the kernel's fingerprint unchanged, reaching other packages only through capabilities it declares (C-13) — so extending the CRM means adding a package, not forking a platform. Every mutation in the composed application goes through a module service or a named workflow and leaves an audit event and a step-level trace behind it (C-16).

The dependency posture is part of the definition here: the framework itself has zero third-party runtime dependencies — Node 22, its built-in SQLite adapter, its built-in HTTP server and test runner (C-17). That is a property of the framework, not of your application; the first library you add is yours to carry.

Open source, with the distribution mechanics stated

The licence is MIT, confirmed by an ADR rather than assumed, and it covers this framework only — it decides nothing about the licence of the applications generated with it, which belong to their authors. That is the 'open source CRM framework' reading in full: source you may keep, read and change.

Distribution is narrower than the phrase usually implies, and this site states it rather than letting a reader discover it: nothing installs from npm. The project bootstrap scaffolds a working project from a checkout of this repository, the name reserved on the registry is still an empty placeholder, and either way the framework is vendored into the project — so upgrading means merging changes into a copy, not bumping a version (L-08).

What the term does not buy

Being a framework does not make the output deployable, and this one is explicit about it. There is no authentication, tenancy or RBAC, and the server is local-development-only (L-01); persistence is Node's built-in SQLite adapter (L-02); there is no hosted CRM, free tier or account to sign up for — the output is an application in your repository that you run (L-07).

Being a framework also does not make it measurably better than the alternatives. No benchmark has compared building on Accordo with building from scratch or with adopting a product: the build benchmark protocol is published and has not been run, so any number quoted for this project is not ours (L-03).

The evidence this page rests on

Claims and limitations are printed from site/claims.json word for word. Job statuses come from docs/benchmarks/jobs.json; a job with no page of its own is listed with its status rather than linked.

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-13 A customer-authored domain package attaches and detaches with the kernel's fingerprint unchanged, and reaches another package only through a capability it declares.

    LimitThe scaffold that starts one writes an empty package and nothing else: no business logic, no composition, no global identity-uniqueness check. There is no registry, no marketplace, no publication and no sandboxing — package code runs with the host process's authority. Detaching leaves its data behind; there is no uninstall.

  • 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-17 Zero third-party runtime dependencies. Node 22 and a checkout — no build step, no bundler, no framework underneath your framework.

    LimitDevelopment dependencies and the eventual PostgreSQL adapter are separate questions. Having no runtime dependencies is a property of the framework, not of whatever you add on top of it.

Limitations

  • L-01 No authentication, tenancy or RBAC. The server is local-development-only. An actor header is an assertion, not an identity. Do not expose it to a network.
  • L-02 SQLite only. Persistence is Node's built-in SQLite adapter. PostgreSQL is on the Production Spine track and is not implemented.
  • L-03 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.
  • L-07 This is a framework, not a product you sign up for. There is no hosted CRM, no free tier and no account. The output is an application in your repository that you run.
  • L-08 Ownership today means copying source, not installing a dependency. There is a project bootstrap and there is no published package, and the two are different facts. The repository's bootstrap command scaffolds a project that boots, reports `valid` from `app inspect` and exits 0 from `project doctor`, offline and with no install — run from a checkout of this repository. The package published under the reserved npm name is still an empty 0.0.1 placeholder, so the `npm create` route installs nothing until a human publishes it. Either way the framework is vendored into the project rather than depended on by version: you own the result outright, and upgrading means merging, not bumping.

Jobs it covers

Documented in

Proved by