projectadg last reviewed 2026-05-21

Zinga suite — 7-product hospitality + accounting SaaS replacement strategy

Context

Aspire spent significant subscription fees on third-party SaaS (RMS Cloud, Fresha, STAAH, Restoke, Foodrazor, Xero) — many of which had UX gaps, vendor lock-in, or per-seat pricing that scaled badly with Aspire's multi-venue growth. The Zinga suite is Aspire's strategic in-house replacement: 7 products that progressively replace each external vendor while remaining commercially sellable as standalone SaaS to other hospitality businesses.

Architecture

graph LR PMS["Zinga PMS"] -.replaces.-> RMS["RMS Cloud"] CM["Zinga CM (LIVE)"] -.replaces.-> STAAH["STAAH"] K["Zinga Kitchen (LIVE)"] -.replaces.-> RST["Restoke"] PR["Zinga Procure (LIVE)"] -.replaces.-> FR["Foodrazor"] L["Zinga Ledgr"] -.replaces.-> XERO["Xero"] PH["Zinga Phone (LIVE)"] -.replaces.-> RC["RingCentral"]

Detail

The 7 products

#ProductReplacesStatusURL
1Zinga PMSRMS Cloud (property management)Phase 0 — 10 modules scaffolded—
2Zinga BookingFresha (booking system)Phase 0 — 10 modules + 5-step onboarding + calendar day view—
3Zinga Channel ManagerSTAAH (channel manager)LIVEcm.getzinga.com.au
4Zinga KitchenRestoke (kitchen ops)LIVE — 7 phases shipped + integrates with Zinga Procurekitchen.zeehost.ai
5Zinga ProcureFoodrazor (procurement)LIVE — 15 routes, demo data onlyprocure.zeehost.ai
6Zinga LedgrXero (accounting)Turborepo, Phase 0 complete—
7Zinga Pay(new payment rail)In design — not yet built—

AI helpers (Zinga Ledgr's CFO crew)

Zinga Ledgr ships with 8 named AI helpers — Zac the AI CFO is the lead, with 7 specialist sub-agents. See zeehost for the AI brand strategy.

Architecture pattern

Each Zinga product follows the locked Aspire stack (per aspire-tech-stack):

Domain strategy

Why "Zinga" (positioning)

Zinga is positioned as hospitality + accounting SaaS that doesn't lock you in — Aspire eats its own dogfood (uses Zinga for own venues), then sells to other hospitality businesses. AU-first, eventually expandable.

Phase strategy

  1. Phase 0 — scaffold each module to demo-data UI
  2. Phase 1 — wire one Aspire venue (Six Degrees / Chanya / Venice) as the first real customer
  3. Phase 2 — friendly-beta with 3-5 external venues per no-v2-without-v1-user
  4. Phase 3 — commercial launch (subscription pricing, multi-tenant onboarding)

Open questions

  1. Sequencing: which module ships commercial-paid first? (Channel Manager is LIVE but free for now; Kitchen has the strongest external pull)
  2. Cross-module data — when does Zinga PMS + Booking + CM need to share a customer-record source-of-truth? Probably when 2nd external customer signs.
  3. Zinga Pay — internal payment rail vs lean on Stripe Connect per stripe-connect-marketplace-default?

Provenance

Per-product _STATUS.md lives in each ~/Desktop/Claude/projects/zinga-<module>/ folder. See MEMORY.md for project-specific entries.

Related

🔗 Relationships

graph LR zinga_suite["zinga-suite"]:::self zinga_suite --> zeehost["zeehost"] zinga_suite --> aspire_tech_stack["aspire-tech-stack"] zinga_suite --> coolify_deployment_default["coolify-deployment-default"] zinga_suite --> aspire_llm_gateway_only_egress["aspire-llm-gateway-only-egress"] zinga_suite --> minio_storage_per_app["minio-storage-per-app"] zinga_suite --> no_v2_without_v1_user["no-v2-without-v1-user"] zinga_suite --> stripe_connect_marketplace_default["stripe-connect-marketplace-default"] zinga_suite --> aspire_brand_architecture["aspire-brand-architecture"] classDef self fill:#715EE3,color:#fff,stroke:#291F50;