Atomic CRM and the Supabase starters, or a starting point with CRM machinery already in it?

Where the templates win

Ownership with no argument attached. The research file this page reads — docs/strategy/COMPETITOR_MAP.md, dated August 4, 2026 — records the templates as code-first CRUD starting points under MIT: Atomic CRM is react-admin plus Supabase, distributed through the shadcn registry so the code is copied into your repository; customization is total because it is your code; hosting is wherever you host; and the lock-in column reads none. If the CRM you need is CRUD screens over your own schema on a stack you already know, a template gives you that today, with nothing to learn and nothing to disagree with.

The stack is one this framework does not offer. Atomic's recorded pairing is react-admin with Supabase, while persistence here supports SQLite and dedicated-database PostgreSQL through separate factories (L-02). The file also records .claude/ and .mcp.json checked into Atomic as developer affordances — good for humans working with coding agents, even though it records no runtime MCP surface for any of the templates.

And the kinship should be stated rather than hidden: distribution here today is closer to a template than to a package. 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 file reads Atomic CRM's fork-to-star ratio of about 0.63 as proof that developers want CRM code they own. That is this framework's bet too; the disagreement is only about what the copied code should already contain.

Where this is different

The research file's verdict on the templates is the entire case: no workflow engine, no policy or approval, no audit, no runtime MCP, no CRM semantics — and it calls that emptiness precisely this project's feature list. Here those are the primitives. 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, and a renewal at or above the threshold stops and waits for a named human (C-03), with the refusal asserted by a test rather than promised in a README (C-04). 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 (C-19).

The growth curve is the actual comparison. A template is strongest in its first week, when it is exactly the code you would have written anyway. The file's adjacent row on the do-it-yourself default path records what that costs when the process arrives: every project re-derives validation, approvals, audit and pipeline semantics by hand. Here that machinery arrives generated and consistent, so the fifth object costs roughly what the first one did — which is the opposite of how a hand-extended template ages.

The dependency surface differs by design. This framework is Node 22 and a checkout — no build step, no bundler, no framework underneath your framework; SQLite is Node's built-in adapter and PostgreSQL requires the one pinned pg@8.23.0 driver (C-17). The templates cannot have that property, because their point is to sit inside a stack you already run. Whether that is a cost or a benefit depends entirely on whether that stack is the one you wanted.

How to choose

Choose a template if the CRM is CRUD plus your own logic on your own stack; if react-admin, Refine or Supabase is where your team already lives; if the commercial process is thin enough that writing it by hand is a feature rather than a burden; and if you want no framework opinion between you and the code — the file records total customization and no lock-in, and nothing here contradicts it.

Choose this framework if the process is the product — stages, approvals, discount policy, audit — and you want it generated as reviewable code with the boundaries tested, while choosing SQLite or dedicated-database PostgreSQL (L-02), supplying authentication and hosting, and completing the data operations your deployment needs (L-01, L-06).

If import, export and search are the feature list, neither column claims them: the file records no CRM semantics for the templates, and this framework records those absences in its own ledger (L-06). Both paths end in a repository you own. The choice is only what the first commit already contains, and who wrote it.

What this comparison does not cover

No hands-on evaluation. None of the templates 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.

Nothing about Supabase the product. The file records it only as the backend half of Atomic CRM's stack; no statement about its database, authentication or hosting appears here, because the file carries none.

No code-quality judgement. The file does not review any template's code, so no opinion about react-admin, Refine or any starter's implementation appears here.

No time-to-value or build-rate comparison in either direction — the benchmark that could measure one 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. A dated page is only as good as its date.