Philosophy
Why standards exists, when to use it, and how it differs from spreadsheet-like tools.
standards is a fullstack TypeScript framework for business applications where the schema is the single source of truth — UI, API, validation, and permissions all derive from it. Developers define a protected base; end-users extend it at runtime without touching developer-owned definitions.
Why standards
Business applications have two distinct actors: developers who define structure, and end-users who adapt it to their workflows. standards formalizes this split: anything declared in code is system: true by default — developer-owned, immutable at runtime — while attributes and objects users add through the admin UI are runtime-only and freely editable.
// @noverify
import { object, text } from "@stndrds/schema";
const CONTACT = object({ name: "contacts", label: "Contact" })
.labelExpression("{{ firstName }} {{ lastName }}")
// Declared in code → system: true → protected from user removal
.attribute(text({ name: "firstName", label: "First name" }).required())
// Users can add their own custom attributes alongside, without touching these
.attribute(text({ name: "lastName", label: "Last name" }).required());Users can still add a "LinkedIn URL" or "Preferred language" attribute to the same object without any code change. Those custom attributes coexist with the system ones in the same record type.
When to use standards
- CRM: contacts, companies, pipelines, deal stages defined by developers, notes and custom fields added by users
- ERP: products, orders, invoices with protected financial fields and user-defined metadata
- Internal operations tools: ticketing, onboarding workflows, asset management
- Agent-driven workflows operating on structured business data
- Any application where the data model is partially defined by end-users at runtime
When not to use standards
- Content sites or blogs where data is editorial, not relational
- Consumer-facing apps where users manage only their own profile (no extensible shared entities)
- Apps where the entire schema is fixed and no user extension is needed
- Simple CRUD tools without multi-tenancy or permission requirements
Differences from Notion and Airtable
Notion and Airtable are runtime-only: every field is user-defined, there is no protected developer layer, and there is no type system. standards inverts this: a TypeScript builder DSL defines the base schema, the compiler infers record types end-to-end, pluggable adapters handle persistence and search, and the system: true default protects developer-defined structure from user modification. The result is a typed, auditable foundation on top of which users can still extend freely.