# 11 — Roadmap Build order. Each phase is independently useful: at the end of every phase the business is better off than at the start, even if the next phase never ships. Technology stack and platform are **deliberately not chosen here** — that is the next conversation. Nothing in documents 00–10 depends on the answer. --- ## Phase 1 — One branch can trade **Goal:** a single branch runs its entire day on the system, offline-capable, and the day closes with an accurate cash number. | Module | Scope | |---|---| | Organization | Branch, building, business-day cutoff, **business calendar** (owner-declared closures) | | Access | Users, roles, PIN login, branch scoping, audit log | | Catalog | Categories, items, modifier groups/options, base prices, per-branch price & availability | | POS | Takeaway order flow, walk-in, modifiers, discounts with limits, void with reason, receipt printing | | Payments | Cash, card, wallet; mixed tender; cash rounding | | Shifts | Open with counted float, drawer movements, blind close, variance, Z-report | | Offline | Local store, outbox, sync to centre, idempotency, sync status on screen | | Reporting | Daily sales summary, Z-report, sales by item, voids/discounts by cashier | **Done when:** a branch trades for a full week with the internet cut for a day, and the cash counts reconcile. **Explicitly not in Phase 1:** accounts/credit, inventory, payroll, multi-branch reporting. --- ## Phase 2 — Accounts, credit and billing **Goal:** the thing that makes this business different actually works — tenants buy on account and get billed correctly on their own cycle. | Module | Scope | |---|---| | Customers | Account entity, company/individual, parent linkage, authorized persons | | Billing terms | IMMEDIATE / DAILY / EVERY_N_DAYS / MONTHLY, due days, grace days | | **Employee funding** | `ALL_COVERED` / `NONE_COVERED` / `CAPPED_PER_EMPLOYEE`, per-person overrides, cap periods, cap accounting | | POS | Charge to account, account search by code/name/office/phone, **split settlement on cap overflow**, charge and split slips | | Credit control | Credit limits, blocking, supervisor override, offline provisional checks | | Billing | Billing runs, period grid, invoice generation, statement groupings | | Collections | Payments and allocations, receiving payment at the POS, credit notes, write-offs | | Aging | Aging buckets, overdue automation, auto-hold, reminders | | Reporting | AR aging, unbilled charges, statements with cap summary, DSO, credit and cap exceptions | **Done when:** a full month runs end-to-end — charges accumulate, invoices issue on four different cycle types, an employee exhausts a cap and the excess is settled personally on one order, payments allocate, and one account goes overdue and is auto-held without manual intervention. **Highest-risk phase.** Build it slowly and reconcile it against a manual spreadsheet for the first two cycles. --- ## Phase 3 — Multi-branch rollout **Goal:** all five branches live, with the owner seeing them side by side. | Module | Scope | |---|---| | Branches | All five configured, per-branch pricing and availability, regions | | Cross-branch | Cross-branch account charging, cross-branch payment collection | | Sync | Hardening under real multi-branch load; offline alerting; conflict reporting | | Reporting | Branch comparison, consolidated sales, owner daily digest (push) | | Exceptions | Anti-fraud report suite, comparative and ranked across branches | **Done when:** the owner in Baghdad can answer "how did Karbala do yesterday, and why is it different from Basrah" without phoning anyone. **Note:** the daily push digest (doc 09 §1) has the best value-to-effort ratio in the whole project. Ship it as early in this phase as possible. --- ## Phase 4 — Inventory and cost control **Goal:** know what things cost and where they go. | Module | Scope | |---|---| | Inventory | Inventory items, units and conversions, per-branch stock, movement ledger | | Recipes | Item recipes, modifier recipe deltas, versioning, automatic deduction | | Suppliers | Supplier master, price lists, per-branch purchasing | | Purchasing | POs, approvals, goods receipt, three-way match, price-change alerts | | Operations | Waste, staff consumption, inter-branch transfers, stock counts | | Reporting | Stock value, shrinkage, waste %, gross margin by item, purchase price variance by branch | **Done when:** a full monthly stock count reconciles and shrinkage is a number the owner trusts enough to act on. --- ## Phase 5 — Expenses, payroll and profit **Goal:** close the loop from revenue to branch profit. | Module | Scope | |---|---| | Expenses | Categories, recording, approval, till pay-out linkage, receipt attachments | | Rent | Contracts, recurring schedules, accrual, renewal and notice alerts | | Employees | Employee records, allowances, optional time clock | | Payroll | Payroll runs, advances (سلفة) and repayment, deductions, payment confirmation | | Payables | Supplier invoices, aging, payments, allocations | | Reporting | **Branch P&L**, consolidated P&L, labour cost %, cash-flow forecast | **Done when:** branch net profit for a closed month matches what the external accountant calculates independently. --- ## Phase 6 — Optimization Nothing here is required to operate; everything here is earned once the first five phases are stable. | Feature | Value | |---|---| | Standing / scheduled orders (doc 04 §8) | Absorbs morning volume with no cashier effort | | Loyalty for walk-ins and individuals (doc 03 §7) | Retention on the non-account segment | | Staff scheduling / rostering | Labour cost planning rather than measurement | | Demand forecasting from sales history | Better reorder sizing, less waste | | Customer-facing display / self-order | Only if queue length justifies it | | Combos and time-window promotions (doc 02 §7) | Margin management | | Accounting-package export | Removes the accountant's re-keying | --- ## Sequencing rules 1. **Never build inventory before the POS is stable.** Recipe deduction on top of unstable orders produces stock numbers nobody believes, and once staff stop believing the stock numbers they stop maintaining them. 2. **Never build multi-branch before one branch is proven.** Every bug multiplies by five and gets harder to observe from another city. 3. **Never build reporting on unstable transactions.** Reports whose numbers change from week to week destroy trust in the system permanently. 4. **Accounts (Phase 2) must precede rollout (Phase 3)**, because rolling out to five branches and then changing how tenants are billed means renegotiating with every tenant. 5. Get **the daily digest** live as early as it can be trusted. It is what makes the owner an active user rather than a spectator. --- ## Immediate next decisions Before Phase 1 begins, three things must be settled: 1. **Platform** — tablet app / desktop app / browser at the counter. This determines how offline-first is implemented and is the single most constraining choice. 2. **Hardware** — terminal, thermal printer with verified Arabic rendering, cash drawer, UPS. Buy and test one full set before committing to five. 3. **Answers to the open questions in [00 — Business Context §6](00-business-context.md)** — particularly whether tenant *packages/entitlements* exist, which would change the billing model in Phase 2.