A declarative runtime, applied to your real problems.

In a software project's accounts, the visible line is initial development. The line that actually weighs, over the following five years, is every change: a new field, a different permission, a control that wasn't needed before, a channel that didn't exist before.

In traditional software that cost is high for a structural reason: domain knowledge is distributed through the code. Knowing that an order can't be confirmed without a delivery address is written in a validation; knowing who may see it is written in an authorisation check; knowing how it appears on screen is written in a page. Three separate places someone has to find, understand and keep consistent.

Pwas moves that knowledge into one place — a declarative description of the domain — and has the backend, the orchestration and the interface all read from it. Changing the domain becomes one edit in one place, not three coordinated edits. That's what makes the five solutions on this page the same thing seen from different angles.

It means you describe what exists and which rules apply, instead of writing instructions for how to do each individual thing.

A concrete example. In a traditional system, adding the concept of a "priority customer" means someone writes: the code to save it, the code to search it, the code to check who may change it, the screen code, the code for the interface exposing it to other systems. Five pieces, five chances to get it wrong, five things to update when it changes.

In the declarative model you write that a "priority" attribute exists on the customer, with certain permitted values, editable only by a given role. From that declaration the system derives everything else: storage, search, permission checks, the field on the screen, external exposure. Not by magic, but because those are mechanical operations that don't need rewriting by hand every time.

The practical consequence, the one customers notice first, is that changes get made and verified on the same day instead of entering a development cycle.

We say it here because it's more useful than a list of advantages, and because we prefer an honest conversation to a badly chosen project.

• When a mature vertical product covers 95% of your case. If you need standard statutory accounting, an accounting package costs less and works better than anything built to measure.
• When the process is simple, stable and nobody intends to change it. The value of the declarative model is speed of change: if nothing changes, you're paying for flexibility you don't use.
• When you need highly specialised computation. Optimisation engines, signal processing, numerical simulation: those belong in specialised code, and Pwas integrates them as external services rather than trying to replace them.
• When nobody in the organisation can describe the processes. The method needs a few hours from people who really know the work. Without those hours the result is a system that describes the wrong process, very quickly.