Full)¶

Status: Accepted
Date: 2026-07-25
Deciders: El

Context¶

Prospects and clients need graduated ways to experience the product before and during commitment: a throwaway sales demo, a paid time-boxed pilot on their real business, and a full engagement. These must not become three separate builds — the architecture is config-driven and multi-tenant, so each should be the same tenant machinery at a different setting.

Decision¶

A tenant carries a mode attribute with three values, each capping behaviour via config, not code: - Demo — fake seeded data, sandbox connectors only, Assist-only autonomy, disposable. For sales. Touches nothing real. - Pilot — real client data and connectors, but scope-limited to the activated module(s), Assist-only (no auto-send), with a hard expires_at date. A paid, time-boxed evaluation; fee credits toward the full build if the client proceeds. - Full — real, unrestricted (within the client's chosen autonomy), permanent. Tenant config gains two fields from day one: mode (demo/pilot/full) and expires_at (nullable). Demo and pilot modes hard-cap autonomy and connector scope regardless of other config — these caps are guardrails, not tunable settings.

Consequences¶

Demo and pilot cost almost nothing to build — they fall out of the provisioning path; the paid pilot qualifies serious prospects and de-risks their decision (fee credits to build); requires the mode/expiry fields and mode-based caps to exist early; pilot scope must be contractually explicit to prevent scope creep.

Alternatives considered¶

Separate demo/pilot codebases — rejected: forks the product.
Free trials — rejected in favour of a small credited pilot fee; free attracts non-buyers and gets ignored.