One description

The product, written down once

Each application starts as a set of small, checked records that say what it offers, who may do what, and how it is sold. Everything else is derived from them.

What the description holds

The product is described as a set of small, checked records:

Experiences: the places a person goes in the app. Search, home, explore, a detail page for one provider or one event, and an agenda of their own.
Actions: everything a person can do, each with one name, such as booking an appointment or following a provider.
Routes: the address of each action the app calls.
Plans and permissions: what each kind of account may do, and what a paid plan adds.
Metering: which actions a plan counts, such as the number of events a provider may publish.

Two sides, one product

People use the discovery side to search, browse and keep an agenda. Providers use the other side to publish events and answer bookings. Both read the same records, so an action appears wherever its record says it should, with the same name and the same rules.

Why records, not documents

A document describes a product to a person. A record describes it to the build as well. Because the records are small and typed, the build can check them, derive from them and refuse a change that breaks them, and a person can still read them.

What one description gives you

One name per action

The button in the app, the permission check and the assistant's tool all use an action's one name, so they cannot drift apart.

Permissions as data

Plans and roles are records too. Who may do what is decided once and applied in the app, in the service and in the assistant.

A product you can read

Anyone on the team can open the description and see what the product does, without reading the code.

Ready for an assistant

Each action can be offered to an AI assistant as a tool, with exactly the permissions of the person asking.

An assistant with the same rules

The Collective will come with an AI assistant. It will be able to list events, publish one, book an appointment, find providers and follow them. Each of these is one of the product's own actions, so the assistant will only be able to do what the person asking could do in the app, and every action it takes will pass the same checks.

Accounts and plans

Anyone can browse, follow and book without paying. Providers join as an owner or as staff, and their plan decides what they can publish. Event publishing is metered: a plan includes a set number of events.

Generated and checked

Nothing derived is written by hand, and a file that drifts stops the build.

Learn more →

Design system and data

One set of tokens and components, and one way for every screen to reach its data.