How Many Tokens Is a Business App? A Complete CRM Under 150k

The short version: a complete CRM can fit under 150,000 tokens of typed metadata: business logic — every object, workflow, action, and permission — stays under 100,000, while declarative UI adds roughly 50,000. The bundled app-crm reference is smaller still: 1,792 lines across 31 files, about 16,000 tokens. That 16k figure describes the reference sample, not the ceiling for a product-grade CRM. Both fit inside a 200k context window. We call this context-sized software: an application small enough for an AI agent to hold, reason about, and refactor whole, while a human reviews the diff.

Count it yourself

The 16k number is not a complete-product benchmark. It is the reproducible count for the CRM reference that ships with the open-source ObjectStack framework:

git clone https://github.com/objectstack-ai/objectstack
find objectstack/examples/app-crm/src -name '*.ts' -not -name '*.test.ts' \
  | xargs cat | wc -l
# → 1,792 lines across 31 files ≈ 16k tokens (at ~4 characters per token)

System	Files	Lines	≈ Tokens	Fits in a 200k context?
Example CRM (app-crm) — objects, views, dashboard, flow, permissions, translations	31	1,792	~16k	Yes — 12× headroom
HotCRM — complete marketplace CRM: 15 objects, 17 flows, 4 dashboards, 2 AI copilots, 4 languages	132	~18,000	under 150k total (business logic under 100k + ~50k UI)	Yes — over 50k headroom
A conventional hand-written CRM codebase	thousands	300k–1M+	millions	No — not close

Same product category, two useful scales: a ~16k reference sample and a complete CRM under 150k. Both remain context-sized; a conventional codebase does not.

Why tokens became the right unit

For fifty years we measured software in lines of code because the binding constraint was the human reader. The reader has changed. Before an AI agent can change a system safely, it has to load the system — and that puts every codebase into one of two regimes:

• System larger than context. The agent greps, samples, and guesses. Its edits are local; its mistakes are global. Every change is archaeology performed through a keyhole.
• System smaller than context. The agent reads everything — every object, every permission rule, every dependency — in one pass. “What breaks if I change this?” becomes an answerable question instead of a hope. A cross-cutting change — renaming a concept across the data model, permissions, API, and UI — is one coherent diff.

That is not an incremental improvement. It is a regime change, and the boundary sits wherever your context window does.

Why the business logic stays under 100k tokens

Not by a compression trick — by deletion. An enterprise application is two things interleaved:

• Decisions. What objects exist, how they relate, who may see which field, what happens when a lead converts. This is your business ontology, and it is genuinely irreducible — nobody but you can decide it.
• Plumbing. Tables, CRUD endpoints, list and detail screens, permission middleware, audit writes. This is essentially identical in every business app ever written — which means it is derivable.

ObjectStack’s bet is to keep only the decisions in the artifact and derive all the plumbing at runtime. In the bundled reference CRM, those 1,792 lines are the decision list — typed, Zod-validated metadata. The database schema, REST API, rendered UI, and MCP tools are computed from it on every boot. Nothing derivable is stored, so nothing derivable can drift. In the complete HotCRM, that separation keeps business logic under 100k tokens; declarative UI adds roughly 50k, keeping the whole application under 150k.

What does not compress

Being honest about the boundary matters more than the pitch:

• Novel algorithms. A pricing optimizer or a custom matching engine is real code and stays real code. The format has escape hatches — actions and plugins are ordinary TypeScript.
• Bespoke, pixel-perfect experiences. Schema-driven UI renders enterprise patterns extremely well; it is not how you build a brand-defining marketing site or a game.
• Exotic integrations. The connector to a thirty-year-old SOAP service is still connector code.

So the claim is narrower than “everything becomes metadata” — and stronger for it: the CRUD-plus-workflow core that makes up most enterprise software is derivable, and the residue that actually matters — the ontology — fits in context.

What changes when software is context-sized

1. Review becomes real. 1,792 lines is a code review. 300,000 lines is a ritual. A human can read the whole diff; the validation gate and the runtime’s permission and audit enforcement stand behind it.
2. Maintenance stops rotting. When the whole system fits in context, the agent refactors it whole instead of patching what it can see. The usual entropy curve of enterprise software — every change a little riskier than the last — flattens.
3. The ontology stays yours. The definition is an Apache-2.0 open format, ordinary files in your repository — readable by humans, writable by any agent, portable across runtimes.

Try the loop

Point your coding agent at ObjectStack — the scaffold ships with AGENTS.md and the skills bundle, so the agent starts with the format’s rules loaded:

npm create objectstack@latest my-app && cd my-app
npx os dev --ui   # the app, running — describe the next change to your agent

Prefer the browser instead of a repo? ObjectOS is the same idea operated for you — build & ask online, with the AI Builder, permissions, and audit built in.