EspoCRM or SuiteCRM, or one custom commercial process as code you own?

EspoCRM and SuiteCRM, the legacy PHP self-host CRMs

People ask this as: espocrm or suitecrm alternative when the process must live as reviewable code

EspoCRM and SuiteCRM are working self-host CRMs that a small or midsize business installs and uses; this is a framework a developer generates one commercial process from. The research this page reads is blunt about the market line: the legacy CRMs own the self-host SMB buyer, not the developer builder, and this project does not compete for that buyer directly. Most readers weighing these options are buyers, and buyers should not choose this. The remainder is a builder with a process no packaged CRM fits. Every fact traces to one dated research file; nothing 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 either product 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.
  • Licence descriptions are factual summaries of published texts, not legal advice.
  • What a business signs up for is the managed Cloud: a free Blueprint-configured workspace, with custom code on a paid Dedicated Cell (L-07).
  • No authentication ships, so nothing here is ready for a sales team to log into (L-01).
  • No prebuilt CRM migration or business-service connector ships. Bounded customer-row import exists; source mapping and complete export remain application work (L-05, L-06).
  • Real customer data cannot go in yet: no export and no erasure path means a subject request cannot be serviced (L-09).
  • 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).
  • No measured comparison in either direction — 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 EspoCRM and SuiteCRM win

They are complete products you can install today. The research file this page reads — docs/strategy/COMPETITOR_MAP.md, dated August 4, 2026 — records EspoCRM at 3.2k GitHub stars and SuiteCRM at 5.6k: legacy PHP open-source CRMs, self-hosted or in Docker, serving SMBs and legacy installs, both AGPL. EspoCRM's metadata and admin-panel customization is recorded as strong; SuiteCRM carries a PHP module framework the file describes as aging. Against this framework's own ledger, the asymmetry is total: no authentication ships, and a deployment must supply the verifier (L-01), no email, calendar or marketing integration (L-05), bounded imports and logical identity links, with no complete export, erasure or physical merge (L-06), no hosted product (L-07), and no place for real customer data yet — with no export and no erasure path, a data-subject access or deletion request cannot be serviced (L-09).

The file's own market summary is the honest headline: together with Odoo, the legacy CRMs own the self-host SMB buyer, not the developer builder, and this project does not compete for their buyer directly. If your company is choosing a CRM to run, this page has no third option to offer — pick between them on their merits, which this page does not evaluate.

Where this is different

The buyer-versus-builder line. The file records zero agent substrate for both: no agent development experience of any kind, and no MCP. Here the agent surface carries most of the point — one command reads checked-in source and reports what an application actually is as deterministic JSON (C-14), and the MCP server exposes project context and narrow write tools, with anything that generates code or destroys state dry-run unless an explicit apply flag is passed (C-18).

What a builder gets instead of an installer. A module manifest becomes a migration, a service, a REST resource, an SDK method and Admin screens with no page code (C-01). Commercial policy is deterministic code rather than a model's judgement, and a renewal at or above the threshold stops and waits for a named human (C-03). Every mutation leaves an audit event and a step-level trace behind it (C-16), and modules evolve through explicit revisions and append-only named migrations rather than rewritten history (C-19). That is machinery for building a process — not a CRM anyone can log into, because there is no login (L-01).

Lock-in shapes differ rather than rank. The file records their lock-in as legacy architecture, alongside AGPL; this repository is permissively licensed, but ownership today means copying source rather than installing a dependency, and upgrading means merging (L-08). Neither shape is free, and this page does not pretend one of them is.

How to choose

Choose EspoCRM or SuiteCRM if you are buying a CRM to use: a self-hosted product for an SMB, customized through an admin panel or an implementation partner — the file records EspoCRM as the stronger of the two on metadata customization — with AGPL acceptable for your deployment.

Choose this framework in the narrow case: one commercial process specific enough that no packaged CRM fits it, which must live as reviewable code in your repository, written mostly by a coding agent — and you supply deployment authentication, hosting, connector mapping and complete personal-data operations; dedicated PostgreSQL and bounded customer imports already exist (L-01, L-06).

No prebuilt migration from EspoCRM or SuiteCRM ships. Bounded JSON customer import can receive application-mapped rows, while complete export remains absent (L-06); this page does not evaluate their export capabilities.

What this comparison does not cover

No hands-on evaluation. Nothing from either product 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 and no pricing. The file enumerates neither product's CRM features and carries no price for either, so this page says nothing about pipelines, reporting, mobile apps or cost.

The words legacy and aging are the file's characterisations, not measurements, and they are repeated here as characterisations only.

Licence descriptions are factual summaries of published texts, not legal advice.

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). When the competitor research is refreshed, this entry must be re-read against it.

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

  • C-19 Generated modules evolve without rewriting history: explicit revisions, a checked-in state file and append-only named migrations.

    LimitThe view is source-only: what the checked-in revisions and migrations say is knowable; what a particular database has actually applied is not.

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-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-05 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.
  • 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-07 The framework is source you run; the Cloud hosts only what a Blueprint expresses. The framework is not a hosted service: its output is an application in your repository that you run. The managed Cloud is a separate offer: a free workspace on shared capacity configured through a Project Blueprint (record types, fields and approval gates), and a paid Dedicated Cell for custom application code.
  • 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-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

Documented in

Proved by