Twenty, or a CRM your coding agent writes as code you own?

Twenty, the open-source CRM platform

People ask this as: twenty crm alternative for building a custom crm with a coding agent

Twenty is an open-source CRM platform with an apps SDK; Accordo is a framework that generates CRM source into your repository. The comparison concerns extension ownership and runtime boundaries. Accordo supports dedicated PostgreSQL and enforced authorization, but requires deployment authentication and operation. Competitor facts retain their dated research scope; no competitor was installed or run.

Where this stops

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

Every fact about another project on this page is single-sourced to docs/strategy/COMPETITOR_MAP.md and dated 2026-08-04. Nothing from another project was installed, configured or run, and there is no network access here to re-verify any of it.

  • No hands-on evaluation: nothing from the other project was installed, configured or run to produce this page.
  • Every competitor fact is single-sourced to docs/strategy/COMPETITOR_MAP.md and dated 2026-08-04; the hedges that file carries (secondary-sourced pricing, unverified self-host MCP parity) are carried here too.
  • No feature-by-feature comparison exists here, and none should be inferred from what this page omits.
  • Licence descriptions are factual summaries of published texts, not legal advice.
  • This framework ships no authentication in any edition — there is nothing gated because there is nothing to gate (L-01).
  • A project bootstrap that runs from a checkout, and no published package: ownership is copying source, and upgrading is merging (L-08).
  • The MCP server is stdio and local only, with no hosted or authenticated endpoint, and it inherits the local process's authority.
  • No claim that a coding agent builds faster or more reliably here than anywhere else — the benchmark has not been run (L-03).

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. Every claim and every limitation is on one page.

Where Twenty wins

As of the research date this page carries, August 4, 2026, Twenty is the largest project in the researched set by GitHub stars — 54.3k — with YC S23 backing, roughly $5.5M raised, and weekly releases. It runs as a NestJS/React/PostgreSQL platform you can self-host with Docker, or as a cloud product; the per-seat cloud pricing in the research file came from third-party teardowns rather than a primary page, so treat the figures there as indicative and do not budget from this page. The headline fact is simpler than any of that: it is a CRM a technical team can run and use, and this framework is not.

Its coding-agent story is real rather than a slide. The research file records an MIT-licensed SDK, a create-twenty-app command, a CLAUDE.md checked into the repository, AI agents inside the product, and native MCP confirmed for cloud workspaces — with self-host parity explicitly unverified. Measured on getting an agent productive against a running CRM this afternoon, that is ahead of where this project stands: `npm create accordo` scaffolds a local development project with the framework vendored in — ownership means keeping that copied source, and upgrading means merging (L-08) — and the MCP server here is stdio and local only, with no hosted or authenticated endpoint (C-18).

And the plain asymmetry. Twenty 2.0 added an apps platform, in-product AI agents and git-backed workspace config, and its customization surface spans a settings UI, APIs and an Apps SDK covering entities, serverless logic functions and UI widgets. This framework ships no authentication at all (L-01), supports SQLite and dedicated-database PostgreSQL (L-02), and is not a product you sign up for (L-07). If what you want is a CRM, that comparison is not close, and pretending otherwise here would forfeit your trust in everything else on this site.

Where this is different

There is one axis, and it is where the extension lives. In the research file's own characterisation, Twenty's customization is deployed into their runtime: the agent writes extensions against their abstractions. Here the agent writes the application. A customer-authored domain package attaches and detaches with the kernel's fingerprint unchanged, and reaches another package only through a capability it declares (C-13). A module manifest becomes a migration, a service, a REST resource, an SDK method and Admin screens with no page code (C-01). One command reads checked-in source and reports what an application actually is — packages, capabilities, resources, actions, policies, providers — as deterministic JSON, then lists its own blind spots (C-14).

Licensing shape, with the counterweight stated in the same breath. The file records Twenty as an AGPL core plus @license Enterprise files covering SSO and advanced RBAC, alongside an MIT SDK, and describes the resulting lock-in as the platform runtime plus AGPL share-alike for derivatives plus those gated files. This repository is MIT with one edition and nothing gated (ADR-023). The counterweight matters more than the contrast: their advanced RBAC sits behind an enterprise licence, and here it does not exist in any edition at all (L-01). Not gated is not the same as included. The file also states that its licence descriptions are factual summaries rather than legal advice, and share-alike questions belong with counsel, not with a comparison page.

The agent surface differs in kind rather than degree. Code generation and destructive operations are dry-run unless an explicit apply flag is passed (C-18), and the first thing a coding agent reads is a deterministic report of checked-in source rather than the state of a running workspace (C-14). That distinction only matters if your review process is a human reading a diff — which is the assumption this whole framework is built on, and is a preference rather than a proof of superiority.

How to choose

Choose Twenty if you want a CRM to use and extend rather than a substrate to build one from; if a hosted option, a community and weekly releases matter; if a platform runtime is a feature rather than a constraint; and if AGPL share-alike on derivatives plus enterprise-gated SSO and RBAC are acceptable for what you are shipping.

Choose this framework in a narrow case: the deliverable is one bespoke commercial process — approvals, discount policy, obligations, handovers — that must exist as source in your repository, reviewed as a diff, with the approval boundary asserted by a test rather than configured in a UI. That case also requires you to supply deployment authentication, hosting, connector mapping and complete personal-data operations; dedicated PostgreSQL and bounded customer imports already exist.

If your actual requirement is SSO or role-based access control, the honest answer is that neither column is this one: the research file puts Twenty's behind an enterprise licence, and this project does not have it in any form.

The research file names Twenty as the strongest competitive threat to this project and says the convergence is in narrative more than in product. Read that as a reason to check its current state yourself before deciding, not as a verdict either way.

What this comparison does not cover

No hands-on evaluation. Nothing from Twenty 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. There is no statement here about Twenty's CRM features, data model, UI, performance, support or roadmap, because that file does not carry them and inventing them would cost more credibility than the comparison is worth.

The hedges the source carries are repeated rather than dropped: cloud pricing is third-party sourced, self-host MCP parity is unverified, and self-host upgrade fragility is recorded there as a documented issue in their tracker (#14705) rather than something reproduced here.

No build-rate or speed comparison in either direction. The benchmark has not been run, and any number quoted for this project is not ours (L-03).

The source's own standing caveat, which is the most important sentence on this page: Twenty could extend its MIT SDK layer downward into genuine code ownership, and that would move this comparison. A dated page is only as good as its date — when that research is refreshed, this entry must be re-read against it.

Common questions

When is Twenty the better choice?

When you want a working open-source CRM application today — UI, hosting story, community — and are happy to extend a platform through its SDK. This framework wins only when the commercial process itself must live as reviewable code in your repository.

Is this a fork of or plugin for Twenty?

Neither. They share nothing: Twenty is an application you run and extend; this generates a bespoke application from your process description. Every fact about Twenty on this page is single-sourced from the dated competitor review, and nothing was installed or run.

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-14 One command tells an agent what an application actually is — packages, capabilities, resources, actions, policies, providers — read from checked-in source, in a single deterministic JSON report.

    LimitSource-only and read-only. It never opens the database, contacts a provider, reads a secret, or reports runtime, CI or authorization state — and it lists those blind spots as machine-readable limitations in its own output.

  • C-17 SQLite is Node's built-in node:sqlite. PostgreSQL requires one pinned runtime driver, pg@8.23.0. There is no ORM, no query builder, no build step and no framework underneath your framework.

    LimitApplications that select PostgreSQL carry pg@8.23.0. The SQLite path still needs no third-party driver. This is not a production-readiness claim and not shared-database tenancy; composition is dedicated-database, not row tenancy.

  • 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.

Limitations

  • L-01 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.
  • L-02 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.
  • 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 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.
  • L-06 Bounded customer imports and logical identity; incomplete data operations. 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-09 Personal-data readiness requires deployment work beyond the foundation. Customer Data Foundation supplies bounded import and identity governance, not complete personal-data operations. Authentication must be supplied by the deployment, and complete subject export and erasure remain absent; the framework alone does not establish compliance or suitability for real customer data. Lead scoring remains deterministic, versioned and explainable.

Jobs it covers