Skip to main content

Release Rollout

The platform controls self-serve organization signup through one audited release policy.

Phases​

  • owner_only: existing accounts can sign in, but new app accounts cannot self-register.
  • private_beta: only email addresses granted private beta access can create an app account.
  • public_beta: anyone can register until the configured public beta account capacity is claimed.

The public beta capacity is admitted app accounts, not staff seats and not portal users. Private beta grants do not consume public beta capacity. Increasing capacity reopens registration immediately; capacity cannot be lowered below the number already claimed. Permanently deleting an admitted public-beta account removes its grant and releases its slot.

Enforcement​

The backend enforces rollout access inside the Convex Auth password signup path before an auth account is created. Public beta capacity is reserved in the same Convex mutation that checks the counter, preventing concurrent signups from exceeding the cap. Failed account creation releases the reservation. An abandoned public reservation expires after 15 minutes, and an unverified public account claim becomes reclaimable after 48 hours when capacity is needed. A verified claim is never reclaimed this way.

Organization creation requires a verified email and performs a second server-side grant check. The check repairs an interrupted signup confirmation by matching the verified account to its reserved email grant. Accounts created before rollout enforcement was first initialized are grandfathered so deployment does not strand existing users. Client UI state is advisory only and is never the enforcement boundary.

Org staff invitation acceptance and tenant portal signup remain separate identity flows. They do not consume public beta capacity and must not be routed through this self-serve organization signup policy.

Platform Operations​

Platform admins manage the policy from Platform → Control plane → Rollout:

  • change the release phase
  • increase or decrease public beta capacity within the claimed-account floor
  • record a future public beta start time for marketing countdown use
  • allow an email address into private beta
  • revoke an unused private beta grant
  • monitor claimed and remaining public beta capacity

Saving the default owner-only policy once initializes the enforcement cutoff even when no visible value changed. Do this before creating post-rollout staff or platform accounts in a new production deployment.

Every rollout settings change, private access grant, and revocation writes a platform governance audit event.

Marketing​

The public system-settings query exposes only marketing-safe rollout state: phase, whether public signup is available, whether capacity is full, and the optional public beta start time. It does not expose counts or allowed email addresses.

The marketing site continues to use the newsletter/get-notified CTA during owner-only and private beta. A countdown or remaining-slots treatment can consume the public rollout state later without changing signup enforcement. When public beta is full, the signup page still accepts private-beta email addresses while the backend rejects other addresses at capacity.

Discounts​

SaaS Stripe Checkout already sets allow_promotion_codes: true. Create coupons and customer-facing promotion codes in Stripe, then give the code to the intended beta customer. A 100%-off promotion code is the appropriate path for a free private-beta agency; usage limits, expiration, eligible products, and first-time-customer restrictions should be configured in Stripe.

Promotion codes affect billing only. They never grant signup access and do not bypass rollout capacity.