CRM for developers: schema as code, typed SDK, MCP

A CRM for developers keeps its data model in your repository and types its API from that model. Its tooling fits how engineers ship: a CLI, a step in CI, and a server that AI agents can call. Search for it in the US in October 2026 and Google's AI Overview gives two answers: a developer-friendly CRM with good APIs and docs, or a CRM you build yourself. A basic custom build takes $20,000 to $40,000 and two to four months, by one 2026 estimate. Standards takes a third path between those two answers. You declare the objects in code, a hosted backend serves them, and your users extend them in the app. The Standards team sums it up as "Notion, for developers". You skip building the API, validation, roles and admin screens, and you keep the schema under review like the rest of your code. Standards does not suit a team that wants a finished sales tool on day one with no code at all.

Before you build on a CRM, check six things: a data model in code, types without codegen, schema changes that keep user data, CI integration, a terminal client and agent access. They come from the r/CRM thread "Developer friendly CRMs?" and the criteria Google's AI Overview listed in the US on 26 October 2026. Each row pairs the question to ask with Standards' answer and the docs page that proves it.

Standards turns a TypeScript declaration into a running CRM backend. You describe each object with builders such as text and select inside an object, group the objects in a bundle, and call standards.bundles.sync from your deploy or from the CLI. After that one call, the workspace serves the object through a REST API under https://api.standards.new/v1/records and validates every write against the declared types. It also applies the permissions of whoever calls and shows your declared views in the admin app, and agents reach the object over MCP. Nothing is generated into your repository: the workspace is the backend. The sync is idempotent. An unchanged bundle costs one GET and writes nothing, and the bundle's hash replaces a version number you would otherwise bump. Attributes come in sixteen types, from text and select to relations and documents, and the API checks each one on write. The bundles documentation lists what a sync changes and why it refuses.

import { bundle, createStandards, 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);

const standards = createStandards({
  baseUrl: "https://api.standards.new/v1",
  apiKey: process.env.STANDARDS_API_KEY!,
  bundles: [crm],
});
await standards.bundles.sync(crm); // { applied: true, hash: "3f9c…" }

The Standards SDK types every create, update, filter and read from the object you declared, with no generated file to keep in sync. Pass your bundles to createStandards and the client exposes one typed query per object, keyed by the camelCase of its name: standards.deals. A select refuses an option you did not declare, so stage: "lost" fails to compile before the request leaves. A filter refuses an attribute that does not exist, which turns a typo into a compile error. Records come back with id, createdAt and updatedAt already typed, and the client revives date attributes as Date objects. The client also refuses an API key in browser code, so the key stays on your server. The type safety page states where the types stop. A relation reads as string even when it holds several ids. An attribute a user added in the app is writable but typed unknown, so you narrow it yourself. Past about 98 chained attributes on one object, inference degrades.

In Standards, nobody can rename, retype or delete in the app what your bundle declares, and whatever your team adds on top survives every sync, as the schema ownership page sets out in one table. Standards calls those declared objects and attributes system definitions. Your sales or support team can still add their own attributes, build kanbans and save filtered tabs on those objects. The sync will not guess a rename in code either: it reads a renamed attribute as one field gone and another appearing, stops with SCHEMA_AMBIGUOUS_CHANGE and writes nothing until you say whether to keep the values. Remove an object from the bundle and Standards demotes it to a user-owned object with its records intact. Nothing your team adds is hidden from you: standards diff lists every attribute, view and object created in the app until your code declares it.

Standards gives a pipeline two commands with exit codes it can read, both listed with every flag on the CLI page on schema and bundles. standards bundles sync finds your bundles, syncs each one after the bundles it depends on, prints applied or unchanged with the hash, and exits 1 at the first refusal. standards diff compares the schema your code deployed with what the workspace runs and exits 0 when they match, 1 when they differ and 2 on an authentication or transport error. Run the first on deploy. Run the second to list where the app departs from your code, such as attributes your team added or a view it reordered. The bundle routes skip rate limiting, so one call carries the whole schema, and a sync result counts the objects it created, updated or deleted and the views it created, updated, adopted or released. A bundle pushed over HTTP holds at most 50 objects and 200 views.

standards bundles sync
code=0; standards diff || code=$?
if [ "$code" -eq 1 ]; then echo "the workspace holds changes your code does not declare"; fi
if [ "$code" -eq 2 ]; then exit 2; fi

Claude Code, Codex and Cursor work on your CRM records through the Standards MCP server, with the permissions of the key you give them. You point the client at https://api.standards.new/v1/mcp, sign in with OAuth (Claude Code, Codex) or pass an API key (all three), and the client receives up to eight tools: search, query, read, write, edit_content, organize, delete and propose_memory. The tool list follows the key. A key that may not write gets no write tools at all, and each call is checked again against the object it touches. The SDK, the CLI and MCP all call the same REST API, so a record an agent creates shows up in your typed queries and in the admin app with the same validation. The handshake lists the objects the key can read and tells the agent to read an object's schema before writing to it; the write is validated either way. The MCP documentation covers OAuth scopes and the refusals a client sees.

claude mcp add --transport http standards https://api.standards.new/v1/mcp

Developers who want a CRM to build on choose among five paths in October 2026, and each trades control against the work left to you. Pick a SaaS CRM for a finished app with an API, a CRM with an app SDK to extend its interface, or an open-source CRM to host yourself. Pick Standards to keep the schema in your repository without building the backend, and a custom build when nothing fits. The table compares them on what each vendor states on its own pages (developer docs, MCP and pricing pages), read on 26 October 2026.

Standards covers the data model, the API, permissions, the admin app and agent access, and it leaves out the tools a marketing team runs: there is no email campaign or marketing automation module. Standards is not open source: its SDK ships under a proprietary license. You run it on the shared host at api.standards.new, on a dedicated instance under your own hostname, or on your own infrastructure with a license, as the security and hosting page sets out. Standards does not publish its prices yet: the team quotes a price per person per month, setup included, on the first call. If you leave, you keep the schema as TypeScript in your repository, and the SDK's all() walks an object 1000 records at a time while export() downloads any query as CSV. The developers page shows the SDK, the CLI and MCP side by side, and the comparison hub sets Standards against other CRMs.