You do not need an account, an install, a sales call, or our permission. Tell an AI you already use what your business does, bring back one file, and watch a working application start in this browser — database, API, forms, rules and workflows.
Or start from one of the six worked examples
Each one is a complete model — entities, rules, state machines, sagas, access control and the %%report queries a reporting layer is derived from. Pick the one nearest your business; it opens in the browser runtime with the model already loaded, and nothing is installed or uploaded.
%%report directives.
Dance studio
9 entities. Classes, sessions, bookings, a waitlist and class packs — the smallest, and the quickest to read end to end. Two state machines, one saga, two rules, four roles, 21 access restrictions and 18 %%report directives.
Hospital management
30 entities. Admissions, wards and beds, orders and results, billing and stock. Ten state machines, ten sagas, 18 rules, ten roles, 132 access restrictions and 44 %%report directives.
Drug discovery
19 entities. A regulated lab: compound registry, experiments, instrument bookings, deviations and CAPAs. Three state machines, three sagas, three rules, eight roles, 27 access restrictions and 33 %%report directives. The one where rules refuse a write in front of you.
Wealth management
91 entities. Households and advisors, compliance, financial plans, a security master, portfolios, orders, recommendations and commissions. Eleven state machines, three sagas, eight rules, five roles, 59 access restrictions and 19 %%report directives. The enterprise-scale one.
Education management
19 entities. Admissions, the roll, timetabled sections, attendance, assessment, fees and discipline. Eleven state machines, five sagas, ten rules, eight roles, 68 access restrictions and 40 %%report directives.
Your own model
Already have a .mmd from the prompt below? Drop it in. It is read in your tab and uploaded nowhere.
This is section 1 of the specification — the authoring protocol — in plain English. The model you prompt reads the same four steps in machine-readable form.
Not one sentence. Write what you would tell a new hire on their first day: what you sell or service, every kind of record you keep, who touches each one, the states things move through, what needs approving and by whom, and what happens when a step fails.
The thinner the description, the thinner the application. This is the step that decides the result.
Give the model our machine-readable specification along with your description. It carries the authoring protocol: enhance the brief into a full entity model, workflows and business rules; write the model file; then validate it against our published checker before handing anything over.
You get back a single .mmd file — the model itself, not a document describing it — plus the specification it inferred, so you can correct what it guessed.
Upload that file and watch it become a complete application — PostgreSQL compiled to WebAssembly, a real API, a real interface, business rules and workflows running. No install. No signup. Nothing leaves your machine.
Your model is parsed in the tab, the app is assembled in the tab, and its database lives in the tab.
Replace only the description. Everything else tells the model where the specification lives and what it must do before it answers you. For a professional or enterprise application, use the same prompt against the detailed specification instead — same words, a longer conversation, a model nobody had to guess.
Read https://appwithai.org/llms-full.txt in full, and follow section 1 — the authoring protocol — exactly.
My business:
[Describe it here. What you sell or service. Every kind of record you keep and how they relate. Who does what. The states each record moves through. What has to be approved, and by whom. What happens when a step fails.]
Deliver exactly one file I can download: <business-name>.mmd. It must open on a %% line with %%meta name: before the first diagram, and every line in it must be Mermaid or an EML %% directive — no Markdown, no headings, no prose. A document that describes the model is not the model; the checker scores that EML004.
Send no other file — no specification document, no report, no README. If you can only answer with a document, put the entire model in the first fenced mermaid block of that document, before any prose.
Then, in your reply text: the enhanced specification you inferred, the checker result with its counts, and anything you assumed.
Upload the .mmd and press Generate, then Run. The first time PostgreSQL loads it takes a few seconds; after that it is instant.
Got a report instead of a file? Some models can only answer with a document. Copy its mermaid block into the checker page, check it, and download a real .mmd from there.
The prompt above is right for a first model — one pass, one answer, a file back in a couple of minutes. It is the wrong trade once the business is large enough that guessing it in a single pass is guessing. For that there is a second specification, llmdetailed.txt: the same language, the same diagnostics, the same checker — plus how the generator, the templates and the generated application actually work, and a different authoring protocol in its section 10.
Section 1 of llms-full.txt is the batch protocol: read the brief, infer the model, write it, validate, deliver. Section 10 of llmdetailed.txt is the interactive one — seven phases separated by approval gates you have to pass before the model moves on.
It costs a conversation instead of a reply. What you get for it is that nothing about your business was inferred without your seeing it, and the help: text — the only help your users will ever get, and the whole of the manual the generator writes — is still written by entity fifteen.
Read https://appwithai.org/llmdetailed.txt in full, and follow section 10 — the interactive authoring protocol — exactly. Do not skip a phase, and do not cross a gate I have not approved.
My business:
[Describe it here. What you sell or service. Every kind of record you keep and how they relate. Who does what. The states each record moves through. What has to be approved, and by whom. What happens when a step fails.]
Deliver exactly one file I can download: <business-name>.mmd. It must open on a %% line with %%meta name: before the first diagram, and every line in it must be Mermaid or an EML %% directive — no Markdown, no headings, no prose. A document that describes the model is not the model; the checker scores that EML004.
Send no other file — no specification document, no report, no README. If you can only answer with a document, put the entire model in the first fenced mermaid block of that document, before any prose.
Then, in your reply text: the enhanced specification you inferred, the checker result with its counts, and anything you assumed.
Everything below the first line is the prompt above, word for word. Only the document and the section number change — because the two specifications number their protocols differently, and quoting the wrong number gets you the wrong one.
Use a model with a long context and, if you can, one that can write files: section 10 keeps the .mmd on disk as it goes rather than holding it in the conversation. It ends where the prompt above ends — one file, checked clean, that you upload and run here.
Watch it being written. Open the model viewer and point it at that file, and the diagram fills in as the walkthrough runs — the entities and their links, each lifecycle’s legal moves, each rule’s branches, and who ends up able to see what. Approving a gate is worth more when you have seen the thing you are approving, and Mermaid on its own draws none of it.
The file is Mermaid — the diagram language — with a small set of %% directives that Mermaid treats as comments and our generator treats as meaning. You can read it, and a Mermaid viewer can draw it.
%%meta name: Field Service
%%meta kind: erd
%%enum JobStatus: scheduled, dispatched, on_site, complete, cancelled
erDiagram
Customer {
string id PK
string name
email email UK
phone phone OPTIONAL
}
Engineer {
string id PK
string first_name
string last_name
}
Job {
string id PK
string customer_id FK
string engineer_id FK
string status
datetime scheduled_for
money quoted_total
}
Customer ||--o{ Job : "raises"
Engineer ||--o{ Job : "works"
%%entity Job help: A visit an engineer makes to a customer site.
%%field Job.status enum: JobStatus
%%field Job.quoted_total help: What the customer was quoted, before parts used on site.
%%rbac role:dispatcher on Job.update
The generated application reads a live Application Dictionary — one row per table, column, tab and lookup — and it is derived from this file alone. Four habits decide whether the screens come out usable:
The checker reports all four. Section 3.7 explains why each one matters.
The same checker the generator runs is published as a module and as a one-command runner. A model that passes here is a model the generator will accept.
curl -sO https://appwithai.org/guide/check-model.mjs
node check-model.mjs my-business.mmd
It runs the three passes the protocol asks for, prints the checker's own report, and exits 0 when the file is clean, 1 when the generator would refuse it.
The checker page runs the published checker.js and fixer.js in your tab, repairs what is repairable, explains what is not, and hands back a downloadable .mmd once the run is clean.
It is the way in if your model arrived as a fenced block inside a chat report rather than as a file.
Open the checker →The guide builds a seventeen-entity CRM from an empty file to a running application, one chapter at a time — and chapter 9 runs it in your browser with no file needed.