Skip to content

Scope

Status: FROZEN — Foundation v1.0

In scope

Platform/SaaS

  • multi-tenancy and tenant isolation;
  • tenant onboarding, suspension, configuration, plans, subscriptions, and entitlements;
  • multiple brands, locations, business units, sites, and domains per tenant where entitled;
  • exactly one primary vertical preset per business unit;
  • additional compatible capabilities with explicit entitlement/billing impact;
  • many-to-many business-unit/location associations;
  • role/membership management and audit trails;
  • usage limits and plan enforcement.

Business configuration

  • platform-governed vertical presets and capability packs;
  • schema-defined offering/resource types;
  • tenant custom fields within bounded types;
  • reusable availability, pricing, inventory, resource, reservation, quote, and booking models;
  • configurable transaction workflows;
  • tenant configuration of platform-defined capabilities without tenant-defined executable vertical logic.

Customer commerce

  • tenant-wide customer identity;
  • business-unit-scoped staff access to customer data where permissions require it;
  • discovery/search;
  • availability and price quotes;
  • enquiries, quotes, reservations, bookings, orders, payments, coupons, cancellation, refunds;
  • order/domain support for multi-line, cross-business-unit checkout within one tenant;
  • reviews, wishlists, customer accounts, communications and notifications;
  • tenant-configured payment accounts through supported payment gateways.

The first implementation may expose narrower checkout flows while preserving the domain ability to evolve to cross-business-unit orders without redesign.

Site delivery

  • Managed Site delivery with site-level and page-level component variants;
  • pages composed from controlled sections;
  • site shell, navigation, themes, reusable sections, SEO, localization, publishing and rollback;
  • Custom plan delivery using Managed, Headless, or contractually defined hybrid delivery;
  • headless APIs/webhooks only where allowed by a Custom contract.

The rendering framework/runtime is a technology decision and is not frozen by Foundation v1.0.

Marketing and channels

  • offers, campaigns, landing pages, attribution and conversion events;
  • social/search advertising channel adapters beginning with providers such as Meta and Google;
  • tenant-connected advertising accounts;
  • catalogs/feeds and analytics integrations;
  • plan-based limits and functionality.

Provider advertising spend is billed directly to the tenant's connected provider account in the baseline.

Commercial model

  • Starter, Growth, Pro, and Custom plans;
  • SaaS subscriptions;
  • optional paid modules/capabilities;
  • capability enablement that may adjust billing;
  • separately scoped custom implementation/services;
  • no default Touriffique percentage/fixed commission on tenant customer transactions.

Internationalization

  • locale-aware platform contracts;
  • localized Managed Sites and customer communications;
  • localized/i18n-aware Tenant Admin experience;
  • i18n-ready Platform Admin experience even if initially operated only in English;
  • locale-aware Custom/headless APIs.

Operations

  • asynchronous jobs, scheduled work, monitoring, audit, configuration history, imports/exports, backup/recovery expectations.

Specific queue/runtime/provider technologies are not frozen here.

Out of scope for the first implementation baseline

These may be introduced later, but are not assumed as core v1 deliverables:

  • full restaurant POS;
  • payroll/HRIS;
  • generalized accounting/ERP replacement;
  • unrestricted tenant JavaScript execution;
  • arbitrary tenant-defined executable workflows;
  • marketplace escrow unless explicitly designed;
  • Touriffique custody of customer funds as a default merchant-of-record model;
  • Touriffique custody of tenant advertising spend;
  • transaction-commission monetization as the standard commercial model;
  • custom backend forks for individual tenants.

Legacy parity requirement

No active legacy capability should disappear silently. Every feature from the Laravel census must be mapped to one of:

PRESERVE, GENERALIZE, REDESIGN, REPLACE, RETIRE, or NEW.

The census itself remains an active migration artifact and may grow as additional legacy behavior is discovered.