How Orbsight manages applications and tenants.

One place to register applications,

Orbsight is a thin vessel over Authorize

Orbsight is the platform where you manage applications and tenants. The administration UI is package-owned in Authorify (built on Shelly); the model and API live in Authorize. Orbsight itself stays a vessel — it composes those, holds server-only secrets, and adds navigation.

The four things the control plane governs

Each concern has exactly one owner. Applications and features are declared by the services that own them; plans are defined by migration; tenants are onboarded and provisioned here.

Self-registered

Applications

Each service declares its own application row in-process (hospitalize → 'hospitality', commercialize → 'commerce'). Orbsight shows the registry read-only — applications are never authored in the UI.

Self-registered

Features

A service registers its feature catalog alongside its application. Admins toggle availability and per-tenant state, but the catalog itself comes from the owning service, not the admin screen.

Migration-defined

Plans

Plans bundle applications and features under a price tier. They change rarely, so they are seeded by database migration — no plan API or authoring UI. Orbsight shows them read-only.

Onboarded here

Tenants

A tenant is created with an initial plan, then its isolated database schema is provisioned. The tenant master app carries the selected tenant as context through Overview, Plan, and Provisioning.

Services register themselves — in-process, no HTTP

Because hospitalize and commercialize depend on Authorize directly, they register their application row and feature catalog by calling Authorize's code in-process against the shared database at boot. The application row is upserted first, because the feature catalog's foreign key requires it.

Cadence decides the mechanism

Applications and features change constantly, so they self-register from code. Plans change only when there is enough built to sell a new tier, so they are migration-seeded. The heavier, rarer change gets the simpler, less-exposed surface.

Three layers decide whether a feature is on

A feature is on for the current UI only when the persisted gates pass — unless a developer override forces it locally.

1 · Plan entitlement

The tenant's subscription is the ceiling. A feature a plan does not bundle is unavailable regardless of any toggle.

2 · Global + tenant state

Within the plan, a platform admin controls global availability and per-tenant enablement (revision-checked, persisted).

3 · Developer override

The Settings 'Feature preview' tab reveals or hides a feature locally, in your browser only. Ephemeral, never saved — for building hidden features.

Plans are keyed by offering and tier

There is no single global 'Basic'. Each product line (offering) has its own tiers, and a plan can bundle apps across services.

$50 / mo

Basic

The entry tier for an offering. A tenant starts on its offering's Basic at provisioning. dental-basic bundles the whole hospitality application (everything the fideicomiso funds).

$100 / mo

Pro

A richer tier, added by a future migration once more advanced applications ship. Reaching a new tier is itself the development effort.

$200 / mo

Ultra

The top tier at platform maturity, bundling the most applications and features. Also migration-defined when the catalog is ready.

Onboarding a tenant, step by step

Create the tenant in the Tenants master app and pick an initial plan — Authorize provisions the tenant and assigns the subscription in one call. Then open the Provisioning tab to create the tenant's isolated database schema.

Schema provisioning runs server-side

The Provisioning tab posts to a platform-admin-gated Orbsight route that holds the Hospitalize service key (never exposed to the browser). It calls Hospitalize's internal endpoints to create the projection, initialize the schema, and poll until it completes.

One database, many schemas

Authorize, commercialize, and hospitalize live as schemas in a single Postgres instance, with a per-tenant patient-data schema (t_<slug>) for each production tenant. Per-service database env vars keep the seam so a service can split onto its own instance later — without code changes.

Open the administration workspace

Enter Orbsight