---
$id: https://apps.ax/
$type: WebSite
$context: https://schema.org
title: "apps.ax — an App deserves to be data, and secure code when it must be"
---

# apps.ax — write one Definition, get every face

**apps.ax is the multi-tenant App interpreter.** You want an App — a
directory, a CRUD/SaaS admin, a marketplace, a store — without hand-building N
frontends for N audiences: a page for humans, a markdown face for agents, a
REST API, an admin. Every App deserves to be **DATA** when it can be (fast,
free, zero per-face authoring) and **secure CODE** when it must be (custom
logic, custom components — first-class, never an escape hatch).

## The problem

Standing up an App today means building and wiring a separate frontend, API,
admin, and agent surface — each by hand, each free to drift from the state it
describes. Multi-tenant means doing it again per tenant. The same four faces,
re-authored every time; nothing compounds, and every face is a place the truth
can diverge.

## The two tiers

- **Data tier (default, free, live today):** `{Definition, seed, theme}` →
  every face — the JSON API, the faceted HTML directory, the
  markdown-of-live-state twin — via one render pass, zero per-face authoring,
  zero marginal cost. This is what powers apis.directory, apis.ax, api.lawyer,
  and api.insure right now: one interpreter Worker mounts four distinct Apps
  as data, by hostname.
- **Code tier (first-class, in progress):** declare custom verbs, custom
  logic, or custom components (npm, React) that run securely in their own
  isolated Worker — no deploy, no cross-tenant risk. You never choose between
  power and safety; you climb to code only when data isn't enough.

## Mount an App, in three steps

1. **Pick an archetype** — Directory, CRUD, Marketplace, or Ecommerce (a
   preset noun/verb set) — or write your own typed Definition.
2. **Mount it** — the interpreter renders every face by hostname from
   `{Definition, seed, theme}`, no build; swap the theme (pure data) to
   rebrand.
3. **Ship** — the page face, the agent face, the API face, and the admin
   face all fall out of one Definition. Climb the customization ladder
   (defaults → theme → override → custom) only if you need to.

## Live proof

<div class="proof-note">One interpreter Worker already mounts four distinct
Apps as data, by hostname, with per-instance themes and zero per-tenant code:</div>

- **apis.directory** — the submit-able API marketplace (the default host)
- **apis.ax** — the curated agent-first API marketplace (a read-only seed)
- **api.lawyer** — the legal possibility surface (a read-only seed)
- **api.insure** — the insurance possibility surface (a read-only seed)

## What's at stake

Without this: rebuilding the same four faces per product, bespoke side
systems that drift from the state they describe, multi-tenant sprawl of
per-tenant code. With apps.ax: an App whose every face is a projection of one
Definition — never authored twice — multi-tenant with zero per-tenant code,
rebrandable by swapping a theme row.

## Docs

Guides, written from the actual behavior of this interpreter:

- https://apps.ax/docs/quickstart — define an App as data, get every face
- https://apps.ax/docs/concepts — the Projection Law + the `{Definition, seed, theme}` model
- https://apps.ax/docs/reference — the faces, and how a Definition maps to them

Every docs page is itself two registers at one URL and is indexed at
https://apps.ax/docs/llms.txt.

## Machine surfaces

- Docs: https://apps.ax/docs (index) · https://apps.ax/docs/llms.txt
- llms.txt: https://apps.ax/llms.txt