Franchise OS — scope & cost proposal from Avocadoo.

The client needs to build a "Franchise OS" on top of Toast POS — to centralize control of menu, recipes, and pricing, sync data across stores, run a franchise approval workflow, and stand up an architecture ready for 50+ stores.

Each phase is an independent milestone that can go live, be signed off, and operate in production before the next phase opens.

Phase 1 — Lean MVP ~$13K

Objective: Centralize operations — HQ controls menu & pricing, Toast data flows into a single system, franchisees have a place to submit proposals — enough to support opening 5 new franchises this year.

Phase 2 — Reporting + Inventory + LMS (FDD) ~$16K

Objective: Deliver FDD-compliant LMS on web first (customer priority) alongside core reporting, BOM/cost engine, and inventory foundation (item master, snapshot, low-stock, Toast BOM deduction, Square Payroll + QuickBooks). Pricing schedule, per-franchise overrides, PO mobile receiving, physical counts, waste/transfer, Toast history backfill, and advanced dashboard features move to Phase 3 to balance budget. Upgrade performance (Azure Service Bus + cache + indexing) for 50-store readiness.

Phase 3 — Mobile + Operations + Deferred Inventory + Simple AI ~$16K

Objective: Flutter mobile (iOS + Android) for HQ + Franchise + Staff — including LMS playback on mobile and mobile-first inventory workflows deferred from Phase 2; the Operations & Checklists module; Simple AI Pack; ticket support; and security review. Advanced AI remains Phase 4.

Phase 4 — AI Layer (optional, year 2)

When to deploy: Once you have ≥12 months of clean data (roughly Q3-2027). This phase is optional and does not need to be signed now. Objective: data → insight → action.

A pragmatic stack for a 5–50 store footprint. Every choice has a reason; not over-engineered, not over-simplified. We always favor boring, proven tech.

A high-level view of how the four user-facing clients, the two backend services, and the external integrations fit together. Everything in the dotted box runs inside the same Azure resource group — one Postgres database is the system of record, one set of secrets in Key Vault, one observability pipeline.

Primary point of contact & named team

A small, in-house Avocadoo team — seven named roles who own delivery end to end. No outsourced sub-contracting unless agreed in writing. Pham Minh Quan is the single point of contact for the Summerfield HQ team throughout the engagement.

DevOps: Terraform, CI/CD, and monitoring setup in P1, then ~0.2 FTE maintenance — owned by Tech Lead with shared rotating capacity inside Avocadoo.

Same total budget, broken down by module and phase — what each feature area costs in USD.

The build cost above is one-time. Running the platform is monthly. Here is what we estimate operating cost at 5 stores vs 50 stores. Azure infrastructure @ 50 stores is budgeted at ~$900/mo (line items in the table below sum to that subtotal). Third-party services (email, CDN, LLM, app-store fees, etc.) are additional — typically ~$225/mo at 50 stores → all-in ~$1,125/mo.

Azure infrastructure

At 5 stores, tiers are right-sized for launch cost: single replica, no zone redundancy, Basic Redis, smaller Burstable Postgres — still a real production stack, not a demo. At 50 stores, Azure scales to support higher sync volume, dashboard load, and blob traffic — ~$900/mo in the table (6 vCPU-class compute, B4ms Postgres, Standard Redis C1, Service Bus, Functions, blob + egress, sampled App Insights). Postgres read replica and multi-zone HA are not in this $900 band; add via expansion RFP if needed.

Third-party services & hidden costs

The brief calls this out as one of the most important sections — fair, because vendors quoting low on build and recouping margin on inflated retainers is a real pattern. Here is how we handle it: 12 months warranty per phase (free), then a single $800/month retainer with a clear hour cap, and $40/hour on-demand beyond that — no multi-tier maze.

Warranty (included free, per phase)

After each phase goes live, 12 months of free warranty & business-flow maintenance on the features delivered in that phase. The warranty covers any behavior that deviates from the accepted UAT criteria — i.e., bugs. It does not cover new features, scope changes, or business-logic adjustments the team decides on after go-live (those are change requests, see below).

Bug-fix SLA (during warranty & under a retainer)

BH = business hours (09:00–18:00 ICT, Mon–Fri). SLA targets apply during warranty and while the monthly retainer is active. Outside business hours: best-effort unless pre-agreed; billed as on-demand if not covered by retainer hours.

Monthly maintenance retainer (after warranty)

One plan after warranty — predictable cost, capped effort. Work that fits within scope and the hour bank is included; anything beyond is on-demand.

Change requests & larger work

A continuous schedule: 3 phases back-to-back with a short Operate & learn window after Phase 1 go-live before Phase 2 build begins — choose only with steady, committed resourcing on both sides.

Five roles from Section 2.1 of the brief × the major modules of the platform. This is the working sketch — it gets locked into a formal RBAC spec during Phase 1 design, then enforced at the API layer (not just the UI). Cells use a compact legend: V view · C create · E edit · D delete · A approve · X execute · — no access. A star (★) means "scoped to their own store(s) only".

A build is only as accurate as the inputs. To keep the timeline honest, here is what we will need from the Summerfield team — grouped by when we would need it. The earlier items unblock Phase 1 design and database modelling; the later ones are about not blocking Phase 2 and Phase 3 once we get there. Business rules, formulas, and calculation logic are listed in the same priority bands below — Critical when they block P1 (menu, pricing, approval, recipe/BOM shape); High when they block P2 (COGS, inventory, deductions, dashboard KPIs). We would rather receive these in a shared folder (Google Drive or Dropbox is fine) than over email — easier to track what is complete.

🔴 Critical — needed before kickoff or in week 1

🟠 High priority — needed before Phase 2 (integration sprint)

Includes integration credentials and the calculation/KPI logic that feeds inventory, cost control, and the HQ dashboard. One record per integrated service for credentials; business-rule docs can live in the same shared folder.

Business rules & calculations — High (before P2)

Integration credentials & confirmations

🟠 High priority — needed before Phase 2 LMS sprint

LMS is delivered in Phase 2 (web) — these inputs must arrive before the LMS build sprint, not Phase 3.

🟡 Medium priority — needed before Phase 3 (mobile + operations)

🟢 Nice-to-have — improves quality but will not block delivery

Section / 11 / is the checklist of what Summerfield provides (credentials, samples, business rules, formulas). This section covers delivery risks and contract assumptions only — we do not repeat those inputs here.

12.1 Key risks & mitigations

12.2 Contract assumptions to verify

Operational rules (recipes, COGS, PAR, KPIs, LMS gates, etc.) are captured as deliverables in / 11 /, not repeated below.

12.3 Proposed contract clauses