Build with us, not just on us.

The awkward side: there's no public directory with dozens of certified partners yet, no portal with ready-made sales material, no certification path formalised into tiers. If you're looking for an industrialised programme, you won't find it here today.

The interesting side: whoever joins now works directly with the team that built the platform, not through an intermediary channel. On the first project we work alongside you, configuration choices get discussed together, and requests coming from the field carry real weight in what gets built next. By definition, that won't last.

We'd rather have a few partners who genuinely know how to work with Pwas than a long list of logos. For anyone building bespoke projects, that's usually the difference that matters.

It isn't about size, but about how you work with clients.

• Those who sell projects, not licences. Pwas's value expresses itself in understanding the client's domain, which is exactly what a good integrator already does better than a product vendor.
• Those whose clients have non-standard processes. If your clients are happy with a vertical product, you don't have a problem to solve. If every project becomes a customisation that then has to be maintained, you do.
• Those with deep vertical domain expertise. Manufacturing, healthcare, public sector, logistics: anyone who knows a sector deeply can build reusable configurations that become their own asset, not ours.
• Those who want to reduce the maintenance cost of their portfolio. It's the most concrete economic argument: maintaining ten declarative projects costs less than maintaining ten bespoke codebases.

What we give. Real hands-on support on the first project, with people from the team rather than documentation. Training on the platform primitives. Direct access for technical questions, without a ticket system in between. Involvement in development priorities, because you're the ones meeting the real problems in the field.

What we ask. That someone on your team invests the time to genuinely understand the declarative model — it isn't much, but it isn't zero, and anyone trying to use it like a traditional framework gets mediocre results. That projects are run with a minimum of rigour on describing the domain, because that's where the quality of the result is decided. And that field feedback comes back, including when it's negative.

Commercial terms are defined case by case, depending on the kind of relationship: resale, implementation under the client's licence, or project collaboration.