Skip to content

Platform Vision

Status: FROZEN — Foundation v1.0
Depends on: none

Vision

Build a configurable operating platform for tourism, hospitality, leisure, rentals, experiences, events, and related service businesses. A business should be able to configure what it sells, how it is priced and reserved, how customers interact with it, how its public website is composed, and how it markets those offerings—without requiring a separate codebase per industry or tenant.

The legacy Laravel application is the migration baseline and first reference tenant, but it does not define the platform's future domain boundaries.

Target organizations

Initial product coverage includes, but is not limited to:

  • Hotels
  • Resorts
  • Spas and wellness businesses
  • Water parks and attractions
  • Villas and luxury estates
  • Marinas
  • Yacht charter businesses
  • Vehicle rentals
  • Vacation rentals
  • Excursion and group-travel operators for schools, colleges, businesses, clubs, and other groups
  • Event managers
  • Destination-wedding businesses
  • Golf courses and clubs
  • Restaurants and beach clubs

The architecture must allow additional verticals to be introduced later without creating a new platform fork.

Product model

flowchart LR
    T[Tenant] --> B[0..N Brands]
    T --> L[0..N Locations]
    T --> BU[0..N Business Units during provisioning]
    BU --> V[Exactly 1 Primary Vertical Preset]
    BU --> C[0..N Additional Compatible Capabilities]
    BU <--> L
    BU --> O[Offerings]
    BU --> R[Resources]
    O --> P[Pricing]
    O --> A[Availability]
    O --> W[Workflow]
    T --> CU[Tenant-wide Customers]

An active operating tenant normally has at least one business unit. Provisioning may temporarily exist before the first business unit is created.

Product outcomes

The platform should let a tenant:

  • operate one or many business units under one organization;
  • maintain one or many brands, locations and public sites;
  • assign exactly one primary vertical preset to each business unit;
  • enable additional compatible capabilities subject to entitlements and billing;
  • publish configurable offerings and services;
  • support instant booking, request-to-book, enquiry, quote, and external-booking workflows;
  • manage availability, inventory, resources, prices, add-ons, cancellation, and payments;
  • maintain one tenant-wide customer identity while restricting staff access by business-unit permissions where required;
  • support orders whose lines may span multiple business units within the same tenant;
  • manage customers, leads, conversations, reviews, and notifications;
  • build a managed website from controlled page/section/component variants;
  • operate a separately contracted Custom site using Managed, Headless, or hybrid delivery without forking the backend;
  • configure SEO, internationalization/localization, domains, integrations, analytics, catalogs, marketing, and advertising;
  • connect tenant-owned payment-gateway and advertising-channel accounts;
  • receive auditable, tenant-isolated operational and financial reporting.

Architectural posture

The platform deliberately chooses a hybrid domain model:

  • strongly modeled transactional concepts for correctness;
  • schema-driven vertical attributes and forms for extensibility;
  • configurable workflows within bounded workflow types;
  • reusable capability packs and platform-governed vertical presets;
  • adapters for external providers;
  • no tenant-specific business logic in the core unless generalized into a reusable capability.

Commercial posture

Touriffique's standard commercial model is:

SaaS subscription
+ optional paid modules/capabilities
+ separately scoped custom implementation/services

The foundation does not assume a Touriffique transaction commission.

Customer payments use tenant-configured accounts from supported payment-gateway options. Advertising channels likewise use tenant-connected accounts, with provider media spend billed directly by the advertising provider.

Internationalization invariant

Internationalization is cross-platform infrastructure. Every engine and API must be locale-aware even when a tenant enables only one language. Locale, currency, timezone and market are separate concepts. Managed and Custom/headless sites consume the same localization contracts.

Tenant-facing administration is localized/i18n-aware. Platform administration is i18n-ready even if its initial operating language is English.

Explicit anti-goals

The platform is not intended to be:

  • a separate application per tenant;
  • a separate application per industry;
  • an unrestricted arbitrary-code website builder;
  • a system where every domain field is unvalidated JSON;
  • a backend fork for Custom-plan clients;
  • a platform that trusts client-supplied tenant identifiers for authorization;
  • a default merchant-of-record/custodian for tenant customer payments;
  • an advertising-spend wallet or ad-spend custodian;
  • a commission-on-every-transaction business model.