Why Standards

Your company needs a CRM with its own deal stages, a back office for orders, a queue for support. A SaaS CRM fits on day one, then answers the field it lacks with a feature request. A low-code builder holds until the first rule it cannot express. A custom build gets the data model right in a day and spends the quarter on the API, the validation, the roles and the admin screens around it.

With Standards you write the data model:

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);

One standards.bundles.sync(crm) later, the workspace serves deals five ways:

• A REST API: list, search, read, create, update and delete under https://api.standards.new/v1/records/deals.
• Validation on every write: stage accepts lead or won, from the API, the app or an agent. In your code, TypeScript refuses anything else before the request leaves, and createdAt comes back as a Date (see Type safety).
• Permissions per object and per action, decided by the roles of whoever calls.
• An admin app: the views you declare next to the object (a table, a kanban, a record page) at app.standards.new, for the people who do the work, who can add their own (see Views).
• Agent tools: Claude Code, Codex or Cursor read and write deals over MCP, within the same permissions.

Nothing is generated into your repository. The workspace is the backend.

Adopt it one object at a timeCopy Anchor Link

Start with the object that hurts most, the one living in a spreadsheet today. Declare it, sync it, and hand the table to the people who used the spreadsheet. Then the next one.

Your users do not wait for you between objects. In the app they add attributes, build kanbans and filtered tabs, and create objects of their own. What they add lives next to what your code declared, and the next sync leaves it in place. What your code declared, they cannot delete or retype. How it works draws that line in detail.

We run our own tools this way. The model catalogue every Standards deployment reads at boot has 42 attributes, 10 view tabs and two work queues, and its repository has no admin component: the Vibecoding walkthrough shows it from schema to production.

What you keep if you leaveCopy Anchor Link

• The schema is TypeScript in your repository, reviewed and versioned like the rest of your code.
• Every record is one call away: all() walks an object 1000 records at a time, and export() downloads any query as CSV.
• The host can be yours: a dedicated instance runs the same API under your hostname, and a licence lets your team run Standards on its own servers.

Security and hosting covers isolation, permissions and where your data lives.

Next stepsCopy Anchor Link

• How it works: workspaces, objects, records, and what your code owns.
• Quick start: declare one object, sync it, and write your first record in five minutes.
• Security and hosting: isolation, roles, sharing, and hosting options.
• Dedicated instances: the same API under your hostname.
• Give your agent this documentation as one file: https://docs.standards.new/llms-full.txt.
• Book a demo