The certified partner directory is coming.

It's the criterion that moves the result most and the one assessed least. In a declarative project, the quality of the outcome is decided in the phase where someone describes your domain: which objects exist, how they relate, which rules genuinely apply, which exceptions matter.

A partner who knows your sector asks better questions, spots the exceptions you forgot to mention and saves you two or three rounds of correction. A technically brilliant partner who is a stranger to your world will build exactly what you described, including the parts you described badly.

When you ask us for a recommendation, that's the first filter we apply.

Sales presentations show screens. They're useful but tell you little, because in a declarative project the screens are the automatically generated part.

The question that discriminates is: show me the domain description from a project you've delivered. A good partner shows it willingly (suitably redacted) and can explain why they structured things that way: why that entity is separate, why that permission is conditional, why that control fires there.

If the answer is vague, or the configuration is a heap of special cases with no structure, the project will be hard to maintain — and maintainability is precisely why you'd choose this approach.

One of the interesting properties of this model is that you can change who maintains the system without rebuilding it. It's worth verifying up front that this really holds in your case.

The concrete questions: will the configuration be yours, versioned where you choose? Who in your organisation will be trained for ordinary changes? Which work will still require the partner? The answers belong in writing at the start, not in a discussion once the relationship has cooled.

A serious partner has no trouble with these questions: they know the value they offer is domain expertise, not control over a configuration file.