Should you build a CRM from scratch, or start from a framework?

Where building from scratch wins

Total control is the real advantage, not a slogan: nothing in your schema is shaped by someone else's idea of what a Company is, and no upgrade ever asks you to reconcile your domain with a framework's opinion of it. That advantage is larger here than usual, because ownership in this project means vendored source rather than a dependency — `npm create accordo`, the published `create-accordo@0.1.0`, scaffolds a project that boots, inspects and passes the project doctor by copying the framework source into it, so upgrading means merging, not bumping (L-08). If the end state was going to be a fork you maintain, starting from your own repository means every convention in it is one you chose.

Work remains on both paths: deployment authentication and hosting, business-service adapters and complete personal-data operations. The synchronous factory uses SQLite; the async factory supports one tenant on dedicated PostgreSQL databases. Shared-database row tenancy and general production readiness are not claimed (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). These bounded contracts reduce framework work; they do not supply an operated CRM.

The third win is the first week. A form, a table and a list against a database you already run is a day of work, with no manifest, no policy version and no migration convention standing between you and a working screen. This framework starts paying on the second commercial rule, not on the first screen, and if there is never a second commercial rule it does not start paying at all.

Where this is different

What you stop writing is the machinery around the record rather than the record itself. A module manifest becomes a migration, a service, a REST resource, an SDK method and Admin screens with no page code (C-01), and generated modules then evolve through explicit revisions, a checked-in state file and append-only named migrations, so history is added to rather than rewritten (C-19). The fifth object costs roughly what the first one did, which is the opposite of how a hand-rolled CRM ages.

The parts a bespoke CRM reaches last are here first. 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 (C-03), and a test asserts that an agent cannot make that decision on the human's behalf, so the boundary is a property of the system rather than a promise in a README (C-04). Every mutation goes through a module service or a named workflow and leaves an audit event and a step-level trace behind it (C-16). None of that is hard to write once. It is hard to write consistently, in every path, under deadline — which is the failure mode the from-scratch CRM actually has, and it shows up as archaeology eighteen months later when someone asks who approved a discount and under which rule.

The dependency surface is deliberately close to nothing: 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). And one command composes the starter's whole application from manifests, drives it end to end, and then prints the things its own inspector says it cannot see (C-22). That last part is the tell — the machinery is built to be interrogated by a coding agent and reviewed by a human, which is a different design goal from the one a hand-rolled CRM is usually optimising for.

How to choose

Build it yourself when an existing stack already supplies the needed process, or when generic CRUD is the whole requirement. Accordo can supply policy, approvals, persistence and bounded import machinery; authentication, hosting, billing and complete personal-data operations still need separate work (L-01, L-06, L-09).

Start from this framework if the process is the product — stages, approvals, discount policy, obligations, handovers — and someone will ask in six months why a number was what it was. It fits when a coding agent is doing most of the typing and you want the output as reviewable source with conventions the agent can read back, and when you would otherwise be deriving approvals, audit and trace by hand for the third time. You keep the repository either way; the question is only whether the first thousand lines in it are yours or the framework's.

What this comparison does not cover

No time or cost estimate, and no build-rate figure. The agent build benchmark is designed and published but has not been run, so no Successful Agent Build Rate exists and any number quoted for this project is not ours (L-03). Nothing on this page says an agent finishes faster here, because that has not been measured.

No comparison to any specific starter, template or boilerplate. This page compares against the empty repository, not against a named project — the dated competitor research the rest of this cluster reads carries facts about other software, and this entry needs none of them, so it uses none.

Nothing about production posture or hosting. There is no hosted CRM, no free tier and no account; the output is an application in your repository that you run (L-07). The comparison assumes you are the one deploying it, and says nothing about how.

Common questions