Custom CRM: three ways to build one, costs and trade-offs

A custom CRM is a CRM whose data model matches your business: the objects you track (clients, households, contracts, orders), the fields on them, the stages they move through and the people allowed to change them. Vendors split the term in two. Creatio calls a customizable CRM a ready-to-use platform you adapt without heavy development, and keeps “custom CRM” for software built from the ground up (creatio.com, updated December 2025). Zendesk draws the same line: a custom CRM is “created specifically for a particular company”, while a customizable one is “a pre-made, off-the-shelf software tool” (zendesk.com, updated August 2025). The split leaves out a third option. On a CRM framework such as Standards, a developer declares your objects in code, and the platform runs the database, the API, the access rules and the screens. Your team then adds its own fields and views in the app. For a firm, the choice turns on who writes the model and who can change it next month.

A custom CRM your team can rely on includes more than a contacts table, whichever route you take to get it. Before you choose a vendor, an agency or a framework, check that the result gives your team the pieces below, and that someone on your side knows who maintains each one after launch:

• objects that match your records, with relations between them (households, contacts, contracts);

• fields, options and stages you can change without waiting for a release;

• roles and permissions per object and per action;

• validation on every write, so bad data is refused before it lands;

• views your team works in: tables, kanbans, filtered tabs and record pages;

• an API for your scripts and integrations, and agent access over MCP;

• backups, and an export of every record if you leave.

You can build a custom CRM from scratch, configure a customizable or no-code CRM, or declare your objects on a CRM framework. The three routes differ on who writes the model, what exists on day one, what it costs, how long a first usable version takes, who maintains it and where it stops fitting.

Build from scratch when the CRM is your product and a product team runs it. A standard sales pipeline sits well in a customizable CRM, while a framework suits a firm whose records do not look like a pipeline and who has, or hires, one developer.

A custom CRM built from scratch costs tens of thousands to $200,000 or more before the first user logs in, by the estimates of the CRM vendors themselves, and the running cost comes on top. The figures differ by source:

Those figures cover the build. The running cost follows: hosting, security patches, backups, and a developer on call when a field changes. A customizable CRM turns that into a subscription plus admin time. Standards is priced per person per month, set-up included, and the team quotes the price on the first call: you pay for the platform, and your developer spends their hours on your objects.

A custom CRM is worth it when your records do not look like a sales pipeline: a household that holds several people, contracts with renewal dates, cases with their own stages. A customizable CRM can follow those records, but each rule its settings cannot express becomes custom development on the vendor's platform, and a from-scratch build costs more again, in money and in months. In return you get a model that matches your work, with roles per object and an API your scripts can call, and someone on your side has to write that model and own it as the firm changes. If nobody on your side writes code, a no-code builder fits better than a framework or a from-scratch build.

Yes for the code, no for the system around it: ChatGPT or a coding tool such as Cursor can write much of the code for a small CRM, and that code is the easy part. A CRM your team can rely on also needs a database with migrations, sign-in, roles per object, an admin screen for the people who do the work, validation on every write, backups and someone who answers when it breaks. Each new prompt rebuilds a slice of that layer differently, which the Standards vibecoding guide calls the place “where vibecoded apps rot”. Let the AI assistant write the code it writes well, and leave the rest to a platform. On Standards, a coding agent writes your schema file and the jobs around it, while the workspace serves the tables, the API and the back office your team works in.

Standards' own model catalog runs this way, with 42 attributes, 10 view tabs, two work queues and no admin component in its repository, as the same guide shows. Claude Code, Codex and Cursor then read and write those records over MCP with your permissions. The ChatGPT app for Standards is not published yet.

Standards is a TypeScript framework for business applications where you declare a CRM's objects once and the platform derives the rest. A developer writes each object with the object() builder: its attributes, their types and options, its relations. One call, standards.bundles.sync(crm), pushes it to the workspace, and each object then gets:

• a REST API;

• validation on every write;

• permissions per object and per action;

• an admin app with the views you declared;

• tools that AI agents call over MCP.

How Standards works walks from the declaration to each of them. Standards writes nothing into your repository and runs no codegen step: TypeScript reads the types from your declaration. It refuses a stage your schema does not declare, or a filter on a field that does not exist, before the request leaves, and records come back with their dates as Date objects. The type safety page of the Standards docs shows each verb's type and where the types stop. Standards runs on its cloud, on a dedicated instance under your hostname, or under license on your own servers.

import { bundle, object, select, text } from "@standards/client";

export const deal = object("deals", "Deal")
  .attribute(text("name", "Name").required())
  .attribute(
    select("stage", "Stage").options([
      { value: "lead", label: "Lead" },
      { value: "won", label: "Won" },
    ]),
  )
  .labelExpression("{{ name }}");

export const crm = bundle("crm", "CRM").add(deal);

On Standards, your users change the model too, without a developer. In the app they add fields, kanbans, filtered tabs and objects of their own, and the next sync from your code leaves them in place; they cannot rename, retype or delete what your code declared. The developers page gives the overview for a technical lead.

You build a custom CRM on a framework one object at a time, starting with the records that live in a spreadsheet today. The steps below follow the Standards quick start, which takes about five minutes for a first typed record.

If your client data sits in one large spreadsheet, our guide to turning a client spreadsheet into a customer database covers step one in detail.

Northgate Partners is a fictional fifteen-person advisory firm, used here as an example. Its client files never fit a sales pipeline: a household holds several people, each person holds contracts, and each contract has a renewal date and a set of supporting documents. The firm had started on a Notion template, the low-cost route our article on using Notion as a CRM walks through, and wanted roles per object and an API for its scripts. Its one developer declares three objects in Standards (households, contacts and contracts) with the relations between them, and syncs them. The advisers open the app the same day and see a table and a record page for each. A week later, the operations lead adds a “referral source” field to contacts and a filtered tab of contracts sorted by renewal date, in the app. The developer's next sync changes the contract stages and leaves both additions in place.

On Standards, the sync will not guess a rename or a retype in code: it stops with SCHEMA_AMBIGUOUS_CHANGE and asks whether to keep the values, before it writes anything.