One domain.
Three engines, one ecosystem.

You almost always start from one component, typically the interpreted backend, because that's where the model becomes clear. Generated interfaces and orchestration make sense as soon as the domain is well described, and they get added without integration, because they read the same model rather than needing to be connected to it.

You build it, and it becomes part of the domain instead of sitting outside it. Pwas.Microservice is the official base for doing so: it provides the contract, authentication, an asynchronous queue, webhooks and model access, and you write only the specific logic. A tool built that way declares itself as a resource and enters the Capability Registry like any other capability — pipelines invoke it, the orchestrator can include it in a compiled and verified plan, and permissions apply there too. It isn't a plugin bolted on at the margins with its own security model to keep aligned by hand.

Low-code platforms build applications through a visual interface and produce an artefact that lives inside that platform. Here the domain is described in structured text files, versioned like any document, and the engine runs them; there's no proprietary visual environment the application resides in, and that changes both who can work on it and what happens if you change supplier.

Up to a point, and it's useful to know that beforehand. The model covers intricate business domains very well — entities, relations, permissions, processes, automation — and highly specialised computation badly; that belongs in dedicated components invoked as declared resources. If the heart of your problem is an algorithm, the declarative model is the setting, not the main course.

It runs on real projects, followed directly by the people who build it. We say it plainly: the partner ecosystem and the public material are still growing, while the product itself is in production. Whoever joins now works in direct contact with the team and has weight on development priorities.

Ordinary development and integration skills, plus a willingness to think declaratively, which is the part demanding the biggest change of habit. Domain changes don't need a programmer: they need someone who knows the processes and has been trained on the configuration structure.

Data sits on a standard relational database queryable with common tools; the configuration consists of readable text files versioned wherever you choose. Both are deliberate choices, because they determine whether staying with a supplier is an economic decision or an obligation.