How an App is served
In the design, every App answers on the Startup's own Domain, derives its screens on each request, and calls one API behind every screen.
In the design, every App a Startup runs answers on the Startup's own Domain, under its own Brand. Each request derives its screens from the live definition and calls one API behind them.
Every Interface on the Startup's own Domain
Each Interface mounts at one path on the Startup's Domain. For leaseclock.com, the API, the screens for each kind of person and the builder all sit under leaseclock.com.
Path on leaseclock.com | Serves | Who signs in | Row |
|---|---|---|---|
/api | every read and every Verb of every Noun | developers and Agents, each with a key | API only |
/mcp | the MCP server over the same Verbs | Agents, each with a key | API only |
/dashboard | the Portal: sign-in, members and seats, the Customer's Offer, usage, keys and invoices | each Customer's owner and members | Portal |
/admin | the Admin: one list, record page, create form and edit form per Noun | the Startup's own team | Screens for the team |
/app | each Persona's home screen, lists and forms, inside its Access Level | people at each Customer | App per Persona |
/studio | SaaS.Studio: the builder, operations and analytics | the founder and operators | SaaS.Studio |
The SDK and CLI ship as the Startup's own leaseclock packages. Headless SaaS serves /api, /mcp, /dashboard and /admin; SaaS adds /app.
Derived on each request
No screen is built ahead of time. Each request names the App by its Domain and path, and reads the live Version of the definition. The rules then project the Noun in view.
| Step | What happens | For leaseclock.com/admin/leases/lease_1 |
|---|---|---|
| 1 | The Domain and path name the Startup and the App | leaseclock.com, /admin: the Admin |
| 2 | The App reads the live Version of the definition | the Version at sha256:9f2c4e1a7b3d |
| 3 | The rules project the Noun into a screen | the Lease record page, titled by residentName |
| 4 | The person's Access level bounds the screen | a team member holding admin sees every button |
| 5 | The screen reads its record through the API | GET leaseclock.com/api/leases/lease_1 |
| 6 | The screen renders in the form the request accepts | HTML for a browser, Markdown for an Agent, JSON for a native client |
A published change reaches the next request with no build per screen. Add renewalNoticeDays?: integer to Lease, and both forms show a number box on the next load, by control-number.
The same request with Accept: text/markdown returns the screen an Agent reads, from the same projection. One screen, three renderings shows all three renderings of one screen.
curl https://leaseclock.com/admin/leases/lease_1 -H "Accept: text/markdown"# Maya Ortiz
| Field | Value |
| --- | --- |
| Resident Email | maya@example.com |
| Starts On | 2025-12-01 |
| Ends On | 2026-11-30 |
| Monthly Rent | 1450 |
| Status | active |
| Property | 14 Elm Street |
Actions: Renew, Terminate, EditOne API behind every screen
Every button calls its Verb through the same API the CLI calls. Renew on the Lease record page sends POST leaseclock.com/api/leases/lease_1/renew, and the Verb refuses or completes there.
A screen holds no rule of its own. A refused Lease.renew shows the reason the Verb gives, the same words a CLI caller reads in the refused Action.
In the design, Verb rules run behind the API, not in the browser. The four guarantees that wait on App guarantees need that move before they print.
Under the Startup's brand
A Customer of leaseclock.com meets only leaseclock.com. The sign-in screen, every email and every invoice carry the Startup's Brand, and no address names the platform's namespace.
A Customer who outgrows the screens keeps the same records at /api. The key from /dashboard reads every record the person sees at /app.
What runs today
Three things serve today:
- the definition, and the term pages generated from it;
- the reads of every Noun, the GET operations, under the Startup's namespace, as
GET /leaseclock.com/leases/{id}; - the 19 Admin rules, at the Admin build pinned to commit 9ab30202.
That Admin build derives its screens in the browser from the definition it is given, and runs Verb rules there too. Admin: derivation rules and edge cases lists every rule it applies.
What a screen costs: depth
Why each Interface adds one function checked by machine, while each screen multiplies Personas, field kinds, data states, Themes and widths that need judgment.
App previews and Versions
In the design, a definition change reaches an App as one Change: previewed on its own Domain, checked screen by screen, then published as a new Version.