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 currently means copying source rather than installing a dependency — there is a project bootstrap that runs from a checkout of the repository and no published package: the repository's bootstrap command scaffolds a project that boots, inspects and passes the project doctor, while the reserved `npm create` name still reaches an empty placeholder and installs nothing, 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.

The second win is everything this framework does not have. There is no authentication, tenancy or RBAC, and an actor header is an assertion rather than an identity (L-01). Persistence is Node's built-in SQLite; PostgreSQL is not implemented (L-02). Import, export, dedupe, merge, bulk edit, saved views and global search do not exist, and none of them has a milestone (L-06). No email, calendar or marketing adapter sends anything to anyone (L-05). Nothing is scheduled, delayed or recurring, because there is no scheduler and no queue (L-04). If those are the hard parts of what you are building — and for plenty of CRMs they are the entire thing — starting here has not reduced your work; you write them once on either path.

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 (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 if the CRM is a form, a list and a few statuses; if the hard part is authentication, tenancy or billing; if you need PostgreSQL on day one; if import, export and search are the feature list rather than an afterthought; or if real customer data goes in immediately, because it cannot go in here yet (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.