Start here

This is the manual for operating a business on Cimplify. Today it covers the foundation everything rests on — modelling the business so its products, prices, schedules, and stock describe what actually happens — and it grows from there.

It is written first for the AI agents that set businesses up and operate them, and for the people working alongside them. So it's precise on purpose: decision rules are explicit and stated as "if this, then that", field names and options are exact, and every page is available as plain Markdown — fetch /llms-full.txt for the whole manual in one request, or /llms/docs/<page>.mdx for any single page.

• Agents and power users: follow the decision tree, then use the grey callout boxes and reference tables for the exact fields to set.
• Business owners: read the plain explanations and worked examples; the grey boxes are configuration detail you can skip.

You do not need to read front to back. Start with The mental model, then jump to the chapter for what's being sold.

The one idea

Cimplify is not a "restaurant app" or a "store app" or a "booking app". It models the physics of a transaction — what actually changes hands when a customer pays — and every kind of business is a mixture of a few building blocks. A salon is mostly bookings with a little retail. A hotel is bookings, food, and shop items at once. A grocer with a deli is packaged goods plus made-to-order food.

So the question is never "what kind of business am I?" It is "what actually moves when someone pays me?"

• A physical thing the customer takes away → you sell it as a product (retail).
• A thing you make from ingredients or parts → you sell it as a recipe (food).
• Your time, a person, a room, a vehicle for a period → you sell it as a service (a booking).

Get that answer right and everything else — stock, pricing, scheduling — falls into place. Get it wrong and you will be fighting the tool. Almost every setup problem traces back to this one question.

How to use this guide

The rules that prevent most mistakes

1. Ask what moves. A thing, a thing-you-make, or time. This single question decides the product type, and the product type decides everything downstream.
2. Model what is true, not a workaround. "Two room types" is genuinely two room types with separate availability — not one number you decrement. If a setup feels like a hack, you have usually answered "what moves?" wrong. See the two-room-types lesson.
3. A count of seats is not a set of real units. "20 class spots" is a number. "Ten specific tables" is ten things you assign and take offline individually. They are modelled differently and the difference matters. See bookable resources.
4. Variants are one product in different forms (sizes, colours), not unrelated products. A shirt and a hoodie are not variants of each other. See retail.
5. One order can mix everything. A single basket can hold a packaged good, a made-to-order meal, and a booking. You never force the business into one mode.

What this guide does not cover

This is about modelling — shaping your catalogue and bookings. It does not cover building a storefront, embedding checkout, payments setup, or the developer SDK and APIs. Those live in the developer documentation. Here, the goal is simply that your data describes your business accurately, so every surface that reads it behaves the way you expect.