Release 3 — and Beyond
Companion: Roadmap Index · Release 1 · Release 2 · Risks & Tradeoffs · ADR-0003 Electron offline-first
R3 takes the platform from a 50-tenant operating product to a 500+ tenant regional category leader with white-label resellers, native staff sub-app capability, kiosk mode, voice-driven workflows, deeper edge AI, full marketing automation, and a clean expansion path into the GCC and Europe. The "beyond R3" section sketches the platform's 3-year horizon: payment orchestration as a separate product line, IoT integration, guest CRM with loyalty, B2B corporate booking, OTA channel manager, autonomous Property Management AI agent, franchise portal, and a marketplace for hotel services.
R3 horizon: year 1.5 → year 2 of the platform. Beyond-R3 horizon: year 2 → year 3+ with ADR-driven gating at each step.
1. Vision
1.1 Vision at the 3-year mark
Ghasi Melmastoon is the operating system for hospitality in the markets the incumbents under-serve. Five hundred properties run their daily operations on the Electron desktop, in seven languages, across nine countries. Resellers in three regions sell the platform under their own brand without forking. A guest checks in at a kiosk in Sharjah using a Wallet pass that was issued from a property in Herat. A housekeeper in Dushanbe records a maintenance issue in Tajik by speaking into the desktop microphone; the transcription, triaged work order, and assignment to a technician happen without typing. A Property Management AI agent watches a chain operator's eight properties and autonomously surfaces the three decisions that need a human. The brand reaches the United Arab Emirates and Bosnia. The platform that started as a guesthouse-first product in Kabul is the credible regional alternative to Cloudbeds, Mews, and the Booking.com OTA model.
1.2 Vision boundary
R3 is not the wave for everything possible. The "beyond R3" section is explicitly conjectural — those capabilities require ADRs, business cases, and dedicated planning before they are committed. R3 is the wave that closes the gap between "scaling product" and "regional category leader" without losing the platform's offline-first, RTL-first, AI-with-HITL, cost-conscious posture.
2. R3 Scope (year 1.5 – year 2)
2.1 IN
2.1.1 Native staff sub-app on mobile (React Native staff sub-mode)
A sub-mode of the existing React Native consumer app for staff workflows that need to happen away from the desktop. Specifically: housekeeper room-update from inside the room, maintenance technician work-order acknowledgment in the basement, GM operational walk-around. The sub-mode is unlocked per device by a staff JWT issued from iam-service; offline-first against a smaller local cache than the Electron desktop.
Capabilities in R3 scope:
- Housekeeping room status update with photo evidence.
- Maintenance work-order acknowledgment + photo + status update.
- GM dashboard read-only view (KPIs, alerts).
- Voice notes capture (handed to voice-transcription pipeline).
- Push-notification triage (replace SMS/email channel for staff alerts).
Out of scope in R3 staff sub-mode (deferred to long-term):
- Front-desk check-in/check-out (stays on desktop).
- Folio operations (stays on desktop).
- Lock issuance (stays on desktop unless mobile-key flow simplifies it).
2.1.2 Kiosk mode for self-check-in
A kiosk variant of the Electron desktop that runs in a public-facing locked-down mode for self-service check-in. The kiosk authenticates the guest by reservation reference + ID document scan, captures the registration document, charges any outstanding balance, issues the key (mobile-key or RFID encoder), and prints a receipt. Falls back to a "summon front desk" affordance if any step fails.
Pilot tenants: 5 in R3 (urban properties with foreign-guest volume); GA in beyond-R3 once kiosk hardware reliability across vendors is proven.
2.1.3 Voice transcription in production
Promote the R2 pilot to production. Pashto and Dari first (the locales we have the most pilot data on); Persian and Tajik in the second half of R3. Used in:
- Housekeeping notes (a housekeeper speaks an observation; transcription becomes a maintenance work order).
- Guest-message drafts (operator dictates an answer; AI cleans it up; HITL sends).
- EOD operator commentary (voice annotation on EOD report; transcription archived).
Targets: ≥ 90% word-error-rate per locale on a per-locale eval set; HITL on every transcription before persisting.
2.1.4 Local-LLM upgrades on edge
Upgrade the desktop ONNX runtime to a small local LLM (e.g., a quantized 1-3B model) in addition to the R1 anomaly heuristics and R2 embeddings. The local LLM serves:
- Offline message-drafting (lower quality than cloud; HITL stricter; "Local model" badge always visible).
- Offline RAG over the per-tenant help corpus (already on-device from R2).
- Offline anomaly explanation (turning anomaly heuristics into operator-readable rationale).
Hardware envelope: must run on the baseline laptop spec (Intel i5 8th gen / 8 GB / SSD) without thermal throttling. Memory budget: ≤ 2 GB during inference.
2.1.5 AI content generation for theme blocks
theme-config-service exposes AI-assisted authoring for content blocks: a tenant types "About us in three sentences in Pashto" and gets a draft; HITL accept/reject; provenance recorded. Language-specific brand voice profiles per tenant. Image generation deferred unless eval clears safety bar.
2.1.6 White-label reseller program
A reseller is a partner who sells Ghasi Melmastoon under their own brand. R3 ships:
- Per-reseller branding override of the
melmastoon.appbrand: domain, logo, color tokens, copy. - Reseller-managed tenant onboarding flow (resellers run their own KYC).
- Per-reseller tenant attribution + revenue share automation.
- Reseller admin surface in control plane.
- Reseller-scoped support routing (resellers handle T1; we handle T2 and platform).
- White-label terms-of-service and privacy-policy templates.
R3 target: 3 active resellers managing ≥ 50 of the 500-tenant total.
2.1.7 Advanced FinOps tooling
- Per-tenant unit-cost dashboard (cost per booking, cost per active operator, cost per AI call).
- Per-tenant tier auto-recommendation (the platform suggests upgrades when usage exceeds tier).
- Reserved-capacity automation across Cloud Run and Cloud SQL.
- Vertex AI committed-use discount management.
- Per-feature cost attribution (which AI feature consumed what budget).
2.1.8 Sustainability reporting
Per-tenant sustainability metrics: energy and water by occupancy (where the property has metering), waste-stream estimates, carbon-intensity per room-night. Surfaces in the GM dashboard and as an exportable report for tenants seeking certifications (Green Key, EarthCheck).
2.1.9 GCC expansion (UAE pilot)
Five UAE pilot tenants in R3. Specific changes:
- Arabic locale parity tested under GCC linguistic norms (different from Iran-region Persian-Arabic mix).
- AED settlement; multi-currency folio with AED + USD + EUR commonly used.
- Local payment rails: card-mainstream (Visa/Mastercard/Amex via Stripe), Apple Pay + Google Pay first-class.
- UAE PDPL compliance review; data residency in asia-southeast1 acceptable per current PDPL stance (revisit per ADR if mandate tightens).
- TRA-compliant guest-registration adapter.
2.1.10 Europe expansion (Turkey + Bosnia pilots)
Turkey and Bosnia are the entry points: Halal-friendly chain target market with strong cultural alignment to our locale strategy. Three Turkish pilot tenants and two Bosnian pilots. Specific changes:
- Turkish + Bosnian locale.
- TRY + BAM settlement.
- Card-mainstream payment; SEPA support added.
- GDPR compliance review; SCCs in place for cross-border data flow; per-tenant DPIA.
- EU region (eu-central1 or eu-west1) added to the multi-region topology for EU tenant data residency.
2.2 OUT (deferred to beyond R3)
- OTA channel manager (Booking.com / Expedia / Agoda).
- Loyalty / rewards programs.
- Restaurant POS / ancillary inventory (spa, activities).
- Deep accounting integrations (QuickBooks / Xero / SAP B1).
- Cross-chain enterprise consolidation (corporate hierarchies, brand families, master-data governance).
- Marketplace for hotel services (transport, tours, food).
- IoT integration (smart room control, climate, lighting).
- B2B corporate booking portal.
- Property Management AI agent (autonomous co-pilot).
3. Epics introduced
| Epic ID | Epic name | Owning service(s) |
|---|---|---|
| EP-MEL-36 | Native staff sub-app (RN sub-mode) | iam-service, bff-backoffice-service, mobile |
| EP-MEL-37 | Kiosk mode for self-check-in | desktop (kiosk variant), reservation-service, lock-integration-service |
| EP-MEL-38 | Voice transcription production | ai-orchestrator-service, desktop |
| EP-MEL-39 | Local-LLM edge runtime upgrade | desktop, ai-orchestrator-service |
| EP-MEL-40 | AI content generation for theme | theme-config-service, ai-orchestrator-service |
| EP-MEL-41 | White-label reseller program | tenant-service, control plane, billing-service |
| EP-MEL-42 | Advanced FinOps tooling | analytics-service, FinOps |
| EP-MEL-43 | Sustainability reporting | reporting-service, property-service |
| EP-MEL-44 | GCC expansion (UAE pilot) | tenant-service, payment-gateway-service, compliance |
| EP-MEL-45 | Europe expansion (TR, BA pilots) | tenant-service, payment-gateway-service, compliance, EU region |
R3 also includes targeted expansions of R2 epics (EP-MEL-19 through EP-MEL-35) in their evolution lanes — chain dashboard maturation, AI capability tuning, theme editor v3, additional lock vendor integrations as opportunities arise.
3.1 R3 quarter-by-quarter rollout
R3 is six months at the front and an additional six months at the back; the second half includes the "tail" between R3 and the conjectural R4. The two quarters of R3 proper are tracked below.
Q3 (M13–M15) — Native staff, kiosk, voice pilot, FinOps
Primary:
- Native staff sub-app (RN sub-mode); staff onboarding flow; permissions; offline cache for staff actions.
- Kiosk mode (Electron variant) — self-check-in, self-checkout, key issuance via integrated encoder.
- Voice transcription production launch in Pashto + Dari; Tajik + Persian in shadow mode.
- Local-LLM edge runtime upgrade — quantized LLM (3–7B) shipped to desktop for local message drafting where bandwidth or sovereignty demands it.
- Advanced FinOps tooling — per-tenant per-feature per-model cost attribution down to the prompt-hash level.
Secondary background work: White-label reseller program design + control-plane scaffolding; sustainability reporting data model.
Q3 exit criteria: Native staff sub-app live with ≥ 30 tenants; kiosk live in ≥ 10 tenants; voice transcription accepted in ≥ 5 tenants per locale; local-LLM smoke-test green on the cohort; FinOps dashboard publicly available to tenants on the higher tier.
Q4 (M16–M18) — Reseller, content, sustainability, geo expansion
Primary:
- White-label reseller program GA — per-reseller branding override of the
melmastoon.appbrand; per-reseller pricing; per-reseller commission; per-reseller portal. - AI content generation for theme blocks — drafted-by-AI, reviewed-by-tenant; respects content-policy guardrails.
- Sustainability reporting GA — energy/water by occupancy; per-property baselines; tenant-facing dashboards.
- GCC expansion: UAE pilot — 5 tenants in UAE; sanctions-aware tenant onboarding; AED currency; Arabic locale primary.
- Europe expansion: Turkey (5 tenants) + Bosnia (2 tenants); TRY + BAM + EUR; Turkish + Bosnian locales added.
Secondary background work: Beyond-R3 conjectures stress-tested commercially; ADR drafting where adoption looks plausible.
Q4 exit criteria: ≥ 500 tenants live across markets; ≥ 3 active resellers; AI content generation used by ≥ 20 tenants; sustainability dashboards live for tenants on the higher tier; GCC + Europe pilots stable and on-track for cohort expansion in R4.
3.2 R3 ASCII timeline (months 13–18)
M13 M14 M15 M16 M17 M18
┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐
Native staff RN │████│ │████│ │░░░░│ │░░░░│ │░░░░│ │░░░░│
Kiosk (Electron) │░░░░│ │████│ │████│ │░░░░│ │░░░░│ │░░░░│
Voice production │░░░░│ │████│ │████│ │░░░░│ │░░░░│ │░░░░│
Local-LLM edge │░░░░│ │░░░░│ │████│ │████│ │░░░░│ │░░░░│
Advanced FinOps │████│ │░░░░│ │░░░░│ │░░░░│ │░░░░│ │░░░░│
White-label rsllr │░░░░│ │░░░░│ │░░░░│ │████│ │████│ │░░░░│
AI content gen │ │ │ │ │░░░░│ │████│ │████│ │░░░░│
Sustainability │ │ │░░░░│ │░░░░│ │████│ │████│ │░░░░│
GCC (UAE pilot) │ │ │ │ │░░░░│ │░░░░│ │████│ │████│
Europe (TR, BA) │ │ │ │ │░░░░│ │░░░░│ │████│ │████│
└────┘ └────┘ └────┘ └────┘ └────┘ └────┘
Staff + Kiosk + Local- Reseller GCC + 500-
FinOps voice LLM + + AI Europe tenant
reseller content pilots mark
scaffold stable
3.3 R3 outcomes (gates)
| Outcome | R3 target | How measured |
|---|---|---|
| Tenants live | 500+ | Control-plane count |
| Reservations / day | 25,000+ | Reservation-service aggregate |
| Active resellers | 3+ | Control-plane reseller registry |
| Native staff sub-app adoption | ≥ 60% of cohort tenants | Sub-app sign-in events / tenant |
| Kiosk mode adoption | ≥ 20% of cohort tenants | Kiosk install registry |
| Voice transcription WER (Pashto/Dari) | ≤ 12% in production | Eval harness on production sample |
| Local-LLM availability | ≥ 80% of qualifying tenants | Edge-LLM telemetry |
| FinOps dashboard usage | ≥ 80% of higher-tier tenants/month | Dashboard view events |
| AI content blocks generated | ≥ 5 / tenant / month average | Theme-config publish events |
| Sustainability dashboard adoption | ≥ 80% of qualifying tenants | Dashboard view events |
| UAE pilot stable | ≥ 5 tenants live for ≥ 60 days | Tenant lifecycle |
| TR + BA pilot stable | ≥ 7 tenants live for ≥ 60 days | Tenant lifecycle |
| Multi-region failover RTO | < 3 min | DR drill record |
| Per-tenant GCP cost (cohort median at 500) | < $30 USD/tenant/month | FinOps |
3.4 R3 staffing evolution
R3 is the wave where the team stops being a pod and starts being an organization with sub-teams.
| Sub-team | Lead | FTE target end of R3 | Charter |
|---|---|---|---|
| Platform | Platform Lead | 4 | iam, tenant, file-storage, control plane, RLS, Pub/Sub, Cloud SQL |
| Reservations & inventory | Backend Eng Lead #1 | 3 | reservation, pricing, inventory, billing, sagas |
| Payments | Payments Lead | 3 | payment-gateway, MFS adapters, PayPal, regional adapters |
| Lock & integrations | Lock Lead | 2 | lock-integration adapters; external partner integrations |
| Notifications & messaging | Notifications Lead | 2 | notification, marketing, WhatsApp/Viber, voice channels |
| Web | Web Lead | 3 | tenant booking web, control plane web, themes |
| Mobile | Mobile Lead | 3 | consumer mobile, native staff sub-app, kiosk variant |
| Desktop | Desktop Lead | 3 | Electron renderer + main, sync engine, edge AI, kiosk variant |
| AI / ML | AI Lead | 4 | ai-orchestrator, eval harness, model registry, local-LLM, voice |
| SRE / FinOps | SRE Lead | 3 | infra, multi-region, on-call, FinOps |
| Security | Security Lead | 2 | KMS, secrets, pen-tests, sanctions screening, compliance |
| Data / BI | BI Lead | 2 | BigQuery, Looker, sustainability data |
| QA | QA Lead | 3 | test harness, two-tenant fixture, contract tests, locale UAT |
| Field ops | Field Ops Lead | 6 | per-market field reps; partner channel managers; reseller relations |
| Compliance & legal | Compliance Lead | 1 + counsel | per-jurisdiction adapters, KYC, sanctions, DPAs |
| PM + Design | PM Lead, Design Lead | 3 + 2 | roadmap, decisions, tokens, RTL, accessibility |
R3 total: ≈ 47–50 FTE plus contractor capacity. The team grows by hire-or-stretch: every new role is hired against a written role brief; no "we'll figure it out as we go" hires.
4. Beyond R3 (year 2 → year 3+)
These capabilities are explicitly conjectural. Each one requires an ADR, a business case, a per-capability risk review, and an explicit wave assignment (R4, R5, …) before it is committed.
4.1 Payment orchestration as a separate product line
The payment-gateway-service already implements adapter pluggability across many rails. There is a credible product opportunity to spin this into a standalone payment-orchestration product for hospitality and adjacent verticals (clinics, education, retail) in our markets. ADR required to confirm the spin-out vs. internal-only model; commercial validation required; legal structure required.
4.2 IoT integration (smart room control)
In-room climate, lighting, blinds, and entertainment controls integrated with the reservation lifecycle. Pre-arrival comfort prep; mid-stay guest control via consumer app; post-checkout energy savings. Hardware partnerships per region (Salto, Honeywell, regional vendors). Edge protocol abstraction in lock-integration-service extended to a room-control port.
4.3 Guest CRM with loyalty program
A first-party guest CRM extending the per-tenant guest record into a cross-stay relationship with preferences, communication history, loyalty tier, and points balance. Per-tenant loyalty programs first; cross-tenant loyalty (in-platform reward currency) explored later. Privacy posture preserved — no cross-tenant guest tracking without explicit consent.
4.4 B2B corporate booking portal
A corporate-account surface that lets a company book stays for its employees across the platform's tenant network with negotiated rates, consolidated billing, and per-employee policy. A separate consumer surface and BFF; cross-tenant interaction handled by search-aggregation-service.
4.5 OTA channel manager
Booking.com + Expedia + Agoda inventory and rate sync. The reservation-service already exposes a channel port reserved for OTA. The work is in the adapter complexity, the rate-parity reconciliation, and the commercial relationship with each OTA. Tenants who want OTA exposure in addition to their direct booking get a one-stop platform.
4.6 Property Management AI agent (autonomous co-pilot)
A higher-order AI capability where the platform watches a chain operator's properties end-to-end and surfaces a small number of high-leverage decisions per day with the rationale. Differentiated from R2's per-capability AI: this is an agent that synthesizes across pricing, occupancy, operations, anomalies, and external context into a daily briefing. HITL-by-design; the agent never executes irreversible actions on its own.
4.7 Franchise / owner portal split
A separate surface for owner-facing reporting and decision-making, distinct from the GM operational surface. Owners often have multiple properties under different operating structures (own-operated, franchised, managed). Portal aggregates across these structures with appropriate isolation.
4.8 Marketplace for hotel services (transport, tours, food)
Third-party services available through the consumer surface: airport pickup, local tours, room delivery from local restaurants. Revenue share per booking. Initially per-tenant per-region; longer-term an in-platform marketplace.
4.9 Beyond-R3 capability prioritization framework
Each beyond-R3 conjecture above must clear the four-gate framework below before being committed to a wave. The gates are evaluated quarterly.
| Gate | Question | Pass condition |
|---|---|---|
| Demand | Is the capability actively requested by ≥ 20% of cohort tenants OR ≥ 2 strategic resellers? | Quantitative request signal in CRM + roadmap input log |
| Commercial | Is the unit economics provable on a 3-year horizon? | Finance signs off on the model (incl. infra cost, ops cost, opportunity cost) |
| Technical | Does the implementation fit the existing hexagonal + event-driven architecture without forcing a foundational rewrite? | Architecture team signs off; no new ADR overturning a R1–R3 ADR is required |
| Strategic | Does the capability strengthen, not dilute, the platform wedge (meta + direct + offline-first + RTL + HITL AI + cost fit)? | CTO + CEO sign off |
A capability that fails any gate is parked, not killed; failed-gate capabilities are revisited each quarterly review with updated evidence.
4.10 Beyond-R3 conjecture summary
| Conjecture | Earliest plausible wave | Required ADR | Primary cross-team dependency |
|---|---|---|---|
| Payment orchestration spin-out | R5+ | Yes | Legal structure + commercial validation |
| IoT smart-room control | R4 | Yes | Hardware partnerships per region |
| Guest CRM with loyalty | R4 | Yes | Privacy/legal review per market |
| B2B corporate booking portal | R5 | Yes | Sales-led discovery |
| OTA channel manager | R4 | Yes | OTA commercial relationships |
| Property Management AI agent | R5 | Yes | AI eval depth + safety review |
| Franchise / owner portal split | R4 | Yes | Tenant request signal at chain scale |
| Marketplace for hotel services | R5 | Yes | Per-region service-provider supply |
The summary is provisional; the prioritization framework above governs which conjecture moves first.
5. Long-term architecture evolution
The current architecture is sound for R1 → R3. Beyond R3, several evolutions become candidates for ADR review.
5.1 Service mesh consideration
At ≥ 50 services and ≥ 500 tenants across multiple regions, the operational complexity of point-to-point service-to-service communication and per-service circuit-breaker logic increases. A service mesh (Istio, Linkerd, or GCP-managed Anthos) becomes a candidate. Trigger: > 35 services in production AND > 3 regions AND > 5 incidents per quarter attributable to inter-service communication failures. ADR required before adoption.
5.2 Event sourcing migration for reservation aggregate
The reservation aggregate accumulates a meaningful history (booking → modification → check-in → folio adjustments → check-out → settlement). Event sourcing the aggregate would simplify audit, replay, and per-aggregate sync. Trigger: sustained tenant request for "show me everything that happened to this reservation" beyond the current event-log capability AND audit framework requirements raise the bar AND > 10% of operator support tickets relate to reservation history. ADR required. Migration plan must preserve current API and only swap underlying storage.
5.3 Separate payment business unit
If §4.1 (payment orchestration as a product line) is pursued, the payment-gateway-service evolves into a separate product unit with its own SLAs, separate compliance posture (potentially full PCI Level 1 if PAN handling expands), and separate commercial model. Trigger: §4.1 ADR approved.
5.4 Edge AI runtime evolution
The R3 ONNX + small local LLM runtime evolves alongside open-model availability. WebGPU acceleration in the renderer (if feasible without compromising the security model), specialized runtimes (e.g., mlc-llm), or vendor-hosted edge inference (e.g., Apple Neural Engine bindings on macOS desktops). Trigger: sustained operator pain on edge AI quality gap with cloud OR new runtime offers ≥ 2× quality for the same memory budget. ADR required.
5.5 Multi-region active-active for billing
Billing-service is per-tenant schema-isolated and currently sized for active-passive multi-region. At scale, an active-active topology for billing reduces latency for chain operators across regions. Trigger: chain operator with properties in ≥ 2 regions reports billing-latency complaints > monthly OR billing per-region failover RTO of 5 min becomes commercially unacceptable. ADR required.
5.6 Tauri re-evaluation
ADR-0003 locks Electron with explicit revisit triggers. Beyond R3, if Tauri 2.x has matured around Node-binding interop and lock vendors begin shipping Rust crates in addition to Node bindings, a Tauri re-evaluation becomes feasible. Trigger: Tauri 2.x stable AND ≥ 2 lock vendors shipping Rust crates AND operator complaint trend on Electron install size from ≥ 3 tenants. ADR required; must address the migration cost (existing operator base, existing vendor adapters in Node).
5.7 GraphQL adoption for one surface
R1 and R2 commit to REST + per-surface BFF resolvers. Beyond R3, if a specific surface (most likely advanced reporting or the corporate booking portal in §4.4) has a strong GraphQL fit, an experimental GraphQL surface is feasible without disrupting the REST contract. Trigger: new surface with > 5 round-trips per page-load over a quarter sustained. ADR required.
6. Long-term commercial evolution
6.1 Pricing tiers
| Tier | Audience | Surface | R3 status |
|---|---|---|---|
| Free Trial | New SMB tenants | Limited room count + limited integrations + no AI | R3 ships |
| Starter | SMB independents | Up to 50 rooms + core PMS + cash + 1 MFS + Stripe | R3 ships |
| Growth | Mid-size + chain pilots | Up to 200 rooms + AI + chain switcher + Looker | R3 ships |
| Enterprise | Large chains + reseller-managed | Unlimited + full AI + dedicated CSM + SLO uplift | R3 ships |
| Reseller | White-label partners | Pricing per partner contract | R3 ships |
6.2 Partner ecosystem
R3 codifies the partner ecosystem launched in R2:
- Sales partners — agencies that sell into a region; revenue share per tenant.
- Implementation partners — local consultancies that handle tenant onboarding for the region.
- Hardware partners — lock and encoder distributors; co-marketing arrangements.
- Payment partners — MFS providers + bank-transfer aggregators per region.
6.3 Marketplace revenue (long-term)
If §4.8 (marketplace for hotel services) is launched, marketplace revenue (commission per service booked) becomes a meaningful share of platform revenue. R3 does not commit to this; the marketplace is a beyond-R3 ADR.
6.4 White-label reseller program — design
R3 ships the reseller program. The design below is the contract between platform and reseller; commercial terms are per-reseller.
Reseller capability stack
| Capability | Per reseller | Notes |
|---|---|---|
Branded control plane (white-label of melmastoon.app) | Yes | Reseller subdomain + theme; "Powered by Ghasi Melmastoon" footer optional per contract tier |
| Branded tenant booking sites (per-tenant theming under reseller umbrella) | Yes | Reseller defines the default theme preset; tenant can refine |
| Branded consumer mobile presence | No (R3) → Yes (R4 candidate) | R3 keeps a single consumer mobile app; reseller branding is a R4 ADR |
| Per-reseller pricing | Yes | Reseller chooses tier and resale margin |
| Per-reseller commission | Yes | Pay-out monthly via billing-service reseller ledger |
| Per-reseller tenant portfolio admin | Yes | Reseller can suspend/onboard tenants under their umbrella |
| Per-reseller reporting | Yes | Looker or Metabase view scoped to reseller's tenants |
| Per-reseller support tier | Yes | Tier 1 / 2 / 3 SLO defined per reseller contract |
| Per-reseller AI policy override | Limited | Reseller can disable AI features; cannot weaken HITL gates |
| Per-reseller white-label of Electron desktop | Limited | Splash + tray icon; cannot rebrand auto-update channel (security) |
Reseller lifecycle
Application ──▶ Vetting ──▶ Contract ──▶ Provisioning ──▶ First tenant ──▶ Quarterly review
↓ ↓ ↓ ↓
Compliance Per-market Reseller Reseller
+ reference pricing + branded dashboard
checks margin portal live
live
Reseller risks (extends platform register)
| Risk | Mitigation |
|---|---|
| Reseller mis-sells the platform | Per-reseller compliance training; mystery-shop spot checks |
| Reseller weakens HITL or security via tenant config | Per-reseller policy override is bounded; AI HITL gates are non-overridable; security pen-test includes reseller surfaces |
| Reseller margin squeeze undercuts platform unit economics | Floor pricing per tier; commission bands |
| Reseller exits — tenant orphaning | "Reseller exit" runbook: tenants either move to direct relationship or to another reseller; no service interruption |
6.5 Long-term financial model (3-year horizon, illustrative)
The model below is illustrative; finance owns the actual model. It is included here so engineering decisions can be reasoned about against expected commercial gravity.
| Year | Tenants | ARR (median per tenant) | Total ARR | GCP cost / tenant / mo | Total GCP / mo | Gross margin (ex-payment-pass-through) |
|---|---|---|---|---|---|---|
| Y1 (R1 → end of R2) | 50 | $400 | $240k | $40 | $2k | ≈ 80% |
| Y2 (R2 → end of R3) | 500 | $600 | $3.6M | $30 | $15k | ≈ 82% |
| Y3 (post-R3) | 1500 | $700 | $12.6M | $25 | $37.5k | ≈ 83% |
The model assumes:
- Per-tenant ARR rises as tenants migrate up tiers and as reseller-managed share grows.
- Per-tenant GCP cost falls as fixed overheads (Cloud SQL HA, Cloud Run min instances, Pub/Sub topology) amortize.
- Gross margin is structurally healthy because hexagonal architecture keeps infra optionality and FinOps discipline keeps AI cost in check.
- Marketplace, payment-orchestration, and OTA channel manager (if launched) bring additional non-SaaS revenue streams not in the table above.
Engineering decisions that materially harm the per-tenant cost line — e.g., uncapped AI calls, premium model defaults, hot-path Vertex AI on every booking — get challenged against this model in the quarterly review.
6.6 Long-term org evolution
R3 ends with ≈ 50 FTE. The 3-year mark targets ≈ 90–100 FTE. The shape of the org evolves:
| Function | R3 end | Y3 end | Notes |
|---|---|---|---|
| Engineering | 33 | 55 | Sub-team specialization deepens; platform team grows; reliability sub-team forms |
| Product + design | 5 | 9 | Per-vertical PMs (hospitality core, payments, AI) |
| QA + reliability | 3 | 7 | Dedicated SRE on-call + perf + chaos engineering |
| Field ops + partner | 6 | 12 | Per-region field teams; reseller program team |
| Sales + marketing | 0 | 8 | Self-serve + partner-led until Y2; direct enterprise sales emerges Y3 |
| Customer success | 0 | 6 | Tier-based CSM; reseller-success roles |
| Finance + ops + legal | 2 | 6 | FinOps lead; counsel per region; payments compliance |
| Leadership | 1 (founder) | 5 (founder + functional VPs) | Hire decision deferred until each function has > 6 reports |
The evolution is hire-or-stretch; functional VPs are hired only when the function depth and team size justify it. Premature VP hires destabilize the engineering culture; late hires bottleneck function output.
7. Risks for the long term
These are the risks whose horizon is years, not months. The full register lives in docs/12-risks-and-tradeoffs.md; a long-term subset:
7.1 Competition from international players (Cloudbeds, Mews, Oracle Hospitality)
International incumbents may target our markets when they see the segment is monetizable. Our defensibility is the cumulative wedge: meta + direct, offline-first, RTL-leadership, AI with HITL, cost fit. No incumbent has more than two of these today. The long-term risk is that one of them invests to close the gap.
- Mitigations: continuous depth on the wedge (meta layer, offline rigor, RTL parity, AI quality); reference customers; community; partner ecosystem; brand investment in target markets.
- Watchpoint: any international incumbent announces target-market strategy; any tenant lost on platform-level capability rather than commercial terms.
7.2 Platform sprawl
500+ tenants, 22+ services, 3+ regions, 9+ locales, multiple AI capabilities, kiosk and staff sub-modes — the surface area is large. Sprawl risks: documentation drift (R-MEL-702), ADR drift (R-MEL-705), incident-rate growth, on-call burden.
- Mitigations: quarterly architecture review; ADR creation policy; documented "no new service without an ADR" rule; service-readiness audits; on-call rotation across timezones; runbook quality enforcement.
- Watchpoint: service count growing faster than tenant count; ADR backlog > 6; incidents per service per quarter trending up.
7.3 Talent retention
Engineers fluent in our markets and our domain are in short supply globally. Losing two senior engineers in a quarter slows R3 measurably; losing five could reset the trajectory.
- Mitigations: equity participation; meaningful problems; remote-friendly across the team's timezones; clear career ladder; internal mobility; reasonable on-call.
- Watchpoint: voluntary attrition > 15% trailing 12 months; senior-engineer open role > 90 days.
7.4 Regulatory shifts in target markets
Sanctions postures, data-residency mandates, KYC requirements, hospitality-licensing rules — all can change with little notice. A change that requires reorganizing where tenant data lives, or restructuring how payments flow, can cost a quarter of engineering.
- Mitigations: hexagonal ports; per-tenant data classification; Plan B IaC for residency; counsel partnerships; quarterly regulatory review per market.
- Watchpoint: sanctions or residency change in any active market; counsel reports new mandate.
7.5 AI quality gap closing across the industry
R2 and R3 invest heavily in AI as a wedge. If AI capability becomes commoditized across the PMS industry, the wedge erodes. Our defensibility shifts to integration depth (AI tied to provenance, HITL, multi-locale, edge inference), not AI per se.
- Mitigations: per-locale fine-tuning; provenance moat; HITL governance lead; edge inference depth; tenant trust accumulated over time.
- Watchpoint: competitor PMS announces a comparable AI capability; tenant feedback on AI quality plateaus.
7.6 Currency and macroeconomic shocks
Our markets are macroeconomically volatile. AFN, IRR, and TJS movements can shift tenant ability to pay. A regional shock (sanctions tightening, conflict, currency crisis) can shrink the tenant base.
- Mitigations: geographic diversification target per release; pause-not-cancel option; outcomes-aligned commercial terms in chains; multi-currency settlement; reserve runway.
- Watchpoint: any active market with currency depreciation > 30% over a quarter; tenant churn concentrated in one market.
7.7 Vendor concentration on cloud + AI
GCP-only + Vertex AI primary creates concentration. The hexagonal ports keep the option to port; the cost of exercising the port is real.
- Mitigations: hexagonal architecture; multi-provider abstraction in
ai-orchestrator-service; documented Plan B IaC; quarterly vendor-relationship review. - Watchpoint: GCP pricing change > 20% on a hot service; Vertex AI capability gap that material; sustained Vertex AI availability incident.
8. Decision points to revisit
| Decision | Revisit trigger | ADR required |
|---|---|---|
| Tauri re-evaluation | Tauri 2.x mature + Rust crates from lock vendors + operator install-size complaint trend | Yes |
| GraphQL adoption | New surface with > 5 round-trips per page-load sustained over a quarter | Yes |
| Multi-cloud activation | Sustained GCP regional outage > 4h or pricing change > 20% or sanctions blocking GCP availability in a target market | Yes |
| Event sourcing for reservation | Audit / replay / per-aggregate sync requirements raised + > 10% support tickets on reservation history | Yes |
| Mobile staff app split | > 30% of housekeeping operators using tablet form-factor; reseller channel demands a mobile staff app | Yes |
| Auto-apply AI dynamic pricing at chain scale | Per-tenant acceptance > 90% sustained 60 days AND chain operator request | Yes |
| OTA channel manager | Sustained tenant request > 30% of cohort + OTA commercial terms negotiated | Yes |
| Marketplace for hotel services | Tenant request signal + commercial validation in 2+ markets | Yes |
| Payment orchestration spin-out | Cross-vertical demand validated; commercial validation passed; legal structure designed | Yes |
| Service mesh adoption | > 35 services + > 3 regions + > 5 inter-service incidents per quarter | Yes |
| Per-tenant white-label of consumer mobile | Reseller request + commercial value justified vs. per-tenant store presence cost | Yes |
The pattern is consistent: trigger > ADR > decision > revisit cadence. We do not change foundational decisions on intuition; the trigger has to fire, the ADR has to be written, and the revisit cadence after the change has to be defined.
9. Outcomes — what success looks like at the 3-year mark
9.1 Scale outcomes
| Outcome | 3-year target |
|---|---|
| Tenants live | 500+ |
| Reservations per day | 50,000+ |
| Geographic markets | 9 (AF, TJ, IR, PK, IQ, EG, UAE, TR, BA) |
| Locales | EN, Pashto, Dari, Tajik, Persian, Arabic, Russian, Urdu, Turkish, Bosnian |
| Resellers | 3+ active |
| Chain operators | 30+ |
9.2 Operational outcomes
| Outcome | 3-year target |
|---|---|
| BFF availability SLO | 99.95% per region |
| Sync conflict rate | < 2 per 1k mutations per tenant per week |
| Desktop cold-start | < 3 s on baseline laptop |
| Multi-region failover RTO | < 3 min, RPO 0 for non-billing |
| AI dynamic-pricing acceptance | > 75% across cohort |
| AI message-drafting acceptance | > 80% across cohort |
| Voice transcription WER | < 8% per locale on production data |
| Lock issuance success rate | > 99.5% per attempt across the cohort |
| Cash-drawer EOD variance | < 1× tenant baseline |
| Tenant onboarding time | < 7 days for SMB self-serve, < 21 days for chain |
| Pen-tests | Quarterly cadence; SOC 2 Type II maintained |
9.3 Commercial outcomes
| Outcome | 3-year target |
|---|---|
| North-star metric (gross booking volume retained in-platform) | > $50M annualized across the cohort |
| Per-tenant GCP cost | < $25 USD/tenant/month at 500 tenants |
| Per-tenant ARR (median) | > $800 USD |
| Retention (annualized) | > 90% |
| NPS (post-stay weighted) | > 50 |
| Operator NPS (cohort weighted) | > 50 |
| Reseller-managed share of new tenants | > 30% |
9.4 Strategic outcomes
| Outcome | 3-year target |
|---|---|
| Platform thesis validated | Meta + direct + offline-first + AI-with-HITL is a defensible wedge no incumbent has fully closed |
| Brand strength | "Melmastoon" recognized in target hospitality industry as the regional category leader |
| Reference base | ≥ 30 publicly referenceable tenants across the cohort |
| Talent | A distributed engineering team of ≥ 40 with domain depth across hospitality + multi-tenant SaaS + AI + offline systems |
| Optionality | Hexagonal ports preserve the option to multi-cloud, multi-AI-provider, and per-region operator deployment without service rewrites |
| Decision discipline | All foundational changes between R1 and the 3-year mark documented as ADRs with triggers, alternatives, and revisit cadences |
9.5 Three-year ASCII roadmap visualization
Y1 Y2 Y3
┌─────────────────────┐ ┌─────────────────────┐ ┌─────────────────────┐
│ R1 (M1–M6) │ │ R3 (M13–M18) │ │ R5+ horizon │
│ Foundations │ ───▶ │ Native staff + │ ───▶ │ Marketplace, │
│ 5 tenants AF/TJ │ │ kiosk + voice + │ │ PMS AI agent, │
│ Cash + Stripe + │ │ reseller + │ │ payment spin-out, │
│ AfghanPaisa pilot │ │ GCC + Europe │ │ IoT, OTA │
│ Electron + edge AI │ │ 500+ tenants │ │ 1500+ tenants │
│ TTLock + Wiegand │ │ Local-LLM edge │ │ 9+ markets │
├─────────────────────┤ ├─────────────────────┤ ├─────────────────────┤
│ R2 (M7–M12) │ │ R4 (M19–M24) │ │ R6+ horizon │
│ AI gateway full + │ ───▶ │ IoT + corporate + │ ───▶ │ Active-active │
│ chain switcher + │ │ loyalty CRM + │ │ multi-region │
│ multi-region + │ │ OTA channel mgr + │ │ for billing, │
│ Iran cohort + │ │ franchise portal │ │ service mesh, │
│ Salto + Assa + │ │ + R3 hardening │ │ potentially │
│ PayPal + 4 MFS │ │ │ │ Tauri re-eval if │
│ 50 tenants │ │ ~800 tenants │ │ triggers fire │
└─────────────────────┘ └─────────────────────┘ └─────────────────────┘
The visualization is a planning aid; commitments live only in the wave files.
9.6 Decision-discipline scorecard at the 3-year mark
| Discipline | Target |
|---|---|
| ADRs published per major change | 100% |
Tradeoffs in 12-risks-and-tradeoffs.md re-justified quarterly | 100% |
| Risks with score ≥ 15 with named owner | 100% |
| Wave files honored or formally amended (not silently abandoned) | 100% |
| Service readiness audits run pre-launch | 100% |
| Pen-tests on cadence (quarterly post-R2) | 100% |
| DR drills on cadence (quarterly post-R2) | 100% |
| Postmortem within 5 business days for every T1 incident | 100% |
| Two-tenant CI fixture green on every PR | 100% |
| AI eval suite green on every model promotion | 100% |
A platform that scales well does so because its decision discipline is high. The scorecard is the cultural commitment behind the technical commitments.
9.7 The thing we will not lose
R1 succeeds because it respects the constraints of the markets we entered. R2 succeeds because it adds AI without abandoning HITL. R3 succeeds because it scales without losing the offline-first rigor and the RTL-first quality bar. The thing we will not lose at the 3-year mark is the operating ethos in the brand name itself: melmastia — the obligation of unconditional hospitality to a guest. The platform is the means; the guest experience and the operator dignity are the ends.
A platform that scales by ignoring its constraints becomes a worse Cloudbeds. A platform that scales by holding to its constraints becomes the regional category leader and a credible global niche player. R3 + beyond is the wave that proves the second is possible.
10. Cross-references
- Platform-wide risk and tradeoff register:
docs/12-risks-and-tradeoffs.md - Strategic specs:
docs/01-product-overview.md,docs/02-enterprise-architecture.md,docs/08-ai-architecture.md,docs/09-lock-and-key-integration.md,docs/10-payments-architecture.md - Per-service bundles:
SERVICE_INDEX.mdandservices/<service>/ - ADR index:
docs/architecture/ - Previous waves: Release 1, Release 2
R3 + beyond is a living document. Each capability that becomes committed (for R4, R5, …) gets its own wave file written in the same shape as R1 and R2, with measurable outcomes, scope IN/OUT, epics, service rollout, infrastructure milestones, quality gates, risks, cost envelope, dependencies, and definition-of-done. The roadmap is not a wishlist; it is a contract.