Vision
From a "feature list" to the operating system of the physical shop — positioning, ideal customer, wedge, and the non-negotiable principles behind Mahalli.
00 — Vision: from a "feature list" to the "shop operating system"
1. The original idea, as stated
A ready-made product for every shop or sector in Saudi Arabia that enables owners of physical shops and stores to:
- Offer Tabby and Tamara (BNPL) to their customers.
- Advertise on Google Maps, Snapchat, and TikTok.
- Design posts and manage their social media accounts.
- Buy an optional accounting product from a store inside the SaaS.
- Create a website with public pages on a custom domain, while the control panel stays on the project's own domain.
2. Critique of the raw idea (why it fails if built as-is)
| Weakness | Why it is dangerous | Adopted solution |
|---|---|---|
| A feature bundle, not a product | Every feature has a stronger specialised competitor: Salla / Zid (online stores), Foodics (restaurants), Qoyod / Daftra / Wafeq (accounting), Canva (design), agencies (ads). A bundle loses on every axis. | Define a backbone none of them own: a Business Graph for the physical shop (identity + catalog + customers + money). Everything else is a module on top of it. |
| Data fragmentation | If each feature is built with its own tables, you get five products behind one UI, and it dies at the first integration. | One data model, tenant_id on every table, one event bus, a mandatory module contract. |
| No clear wedge | "Everything for everyone" means nobody understands why they should sign up today. | One wedge: "your storefront + your payment link in 10 minutes" (see §5). |
| BNPL as a direct service | Tabby and Tamara are SAMA-licensed and have their own merchant terms; the product cannot "offer" Tabby, only facilitate onboarding and integration. | Integrate through a licensed payment gateway (PSP) that supports Tabby / Tamara as payment methods, plus BNPL partner programmes. The platform never holds funds (ADR-0003). |
| Building full accounting | Accounting is a separate market with heavy ZATCA requirements; it would consume the team. | ZATCA-compliant simplified invoicing in the core (because every payment issues an invoice); full accounting is a Marketplace add-on: an embedded partner first, in-house later only if demand is proven (ADR-0006). |
| Ads as an agency | Manual ad management does not scale. | One-click local campaigns from templates, generated from the catalog, brand kit, and location, with a fee on spend. |
| "For every sector" means building per sector | Operationally impossible. | Sector Packs: a configuration layer (page templates, catalog schema, campaign templates, KPIs, recommended modules) with no sector-specific code. |
3. Adopted positioning
Mahalli — the shop operating system: be seen, get paid, stay in control. From one place.
- Not an e-commerce platform (Salla / Zid serve online selling first; we serve the physical shop first).
- Not a cashier / POS system (we integrate with a POS when one exists; we do not replace it in the first phase).
- It is the layer that brings together "digital presence + payment acceptance + local marketing + lightweight management" for a shop owner who has no team.
4. Ideal customer profile (ICP)
Priority 1 (the wedge): a physical shop with a commercial registration (CR), 1–5 branches, no website or a neglected one, accepting mada only, an unmanaged Google presence, and social media run by the owner from a phone. The decision maker is the owner personally. Examples: a café, a salon / barber, a small dental clinic, a car workshop, a perfume or abaya shop, a training centre, a small gym.
Priority 2: small chains (5–20 branches) that need a unified identity and per-branch local presence.
Out of scope for now: pure e-commerce with no physical shop, large enterprises, highly regulated sectors (pharmacies requiring NUPCO / RASD integration, financing).
5. The wedge: "your storefront + your payment link in 10 minutes"
A single onboarding flow:
- Mobile number (OTP) → commercial registration number → automatic verification via Wathq, which pulls the legal name, activity, and address.
- The system proposes a Sector Pack and generates an initial Brand Kit (uploaded or generated logo, colours, tone) and a starter catalog.
- A public storefront is created immediately at
<slug>.mahalli.sa(later on a custom domain) with: about, catalog / menu, branches on a map, a WhatsApp button, and a "Pay" button. - A payment link / QR that accepts mada, Apple Pay, and Tabby / Tamara through the PSP — and a ZATCA-compliant simplified invoice is issued automatically.
- Google Business Profile is connected and hours, photos, and branches are synchronised.
Day-one outcome: the shop "exists" on the internet and on the map, and can collect its first instalment payment. Everything after that (social, ads, add-ons) is upsold from inside the dashboard.
6. Non-negotiable design principles
- One model: a single entity for the shop, the branch, the customer, the item, the payment. No copies.
- The module contract: any new feature is a module that declares its identity, entitlements, routes, events, and settings. No exceptions.
- Mobile first, Arabic first, RTL native: the shop owner runs everything from a phone.
- We never hold funds: every money flow goes through a licensed PSP in the merchant's name.
- AI is an assistant, not the interface: Claude works inside every module (ad copy, review replies, weekly summary) with tenant-scoped tools, and is never trained on merchant data.
- Extend by configuration, not by code: sectors, templates, and campaigns are data, not code branches.
7. What makes this strong rather than weak
- A closed data loop: payments feed customers → customers feed ads (audiences) → ads feed visits → reviews feed content → content feeds the storefront. No specialised competitor owns the full loop for the physical shop.
- Three stacked revenue channels (subscription + a share of payments + ad fees), with add-ons that increase stickiness.
- Naturally high switching cost: the domain, invoices, customer records, and campaigns all live here.
- Distribution through partners (PSP, BNPL, Monsha'at, chambers of commerce, accountants) instead of expensive advertising.
Mahalli Handbook
What Mahalli is, how this handbook is organised, and the rules for contributing to it.
Core, Modules, and Sector Packs
What belongs in the core, the six product modules (payments, presence, social, ads, sites, marketplace), the cross-cutting Copilot, and how Sector Packs extend the product with data rather than code.