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 + Cost ~$16K

Objective: Add multi-dimensional reporting (with Square Payroll + QuickBooks data feeding the HQ dashboard), a BOM/cost engine, full inventory operations (item master, PO + receiving, counts/audits, waste, transfers, low-stock alerts, Toast BOM deduction). Upgrade performance (Azure Service Bus queue + cache + indexing) so the architecture is ready for 50 stores. Read-replica horizontal scaling is carved out into a separate expansion RFP once you reach 50+ stores.

Phase 3 — Mobile + LMS (FDD) + Operations + Simple AI + Support ~$16K

Objective: Flutter mobile (iOS + Android) for HQ + Franchise + Staff; a FDD-compliant LMS (quizzes, learning paths, digital certificates, refresher training, franchisee pre-opening workflow); the Operations & Checklists module (daily/weekly/monthly templates with photo/temp/signature evidence + audit history); a Simple AI Pack (anomaly alert + reorder suggestion + AI Q&A assistant); a lean ticket support system; and an internal security review. Advanced AI (full ML/forecasting/DWH/RAG) is still carved out into 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 — four people who actually own the build 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.

QA & DevOps: shared rotating capacity inside Avocadoo — Tech Lead owns the QA plan; a senior QA engineer is brought in 2–3 days per sprint for test execution and UAT support. DevOps work (Terraform, CI/CD, monitoring setup) is done in P1 and then maintained ~0.2 FTE thereafter.

Same dollars, viewed as "modules you're getting".

The build cost above is one-time. Running the platform is monthly. Here is what we estimate the all-in operating cost looks like at your current scale of 5 stores, and at the projected scale of 50 stores. Numbers are deliberately on the generous side — we would rather over-quote ops and have you save on the bill than under-quote and surprise you later.

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, compute and RAM move to the comfortable side with HA, replication, and read replicas so the system stays responsive on a busy day.

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: a warranty period included free, then a clear retainer with itemized scope, and a 3-year total-cost-of-ownership view so there are no surprises.

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). OOH = outside business hours. P0/P1 outside hours need the Tier C plan or a per-incident emergency fee (below).

Monthly maintenance retainer (after warranty)

Pick the tier that matches how much ongoing work you expect. Tier B is what we would recommend for a 10–25 store operation; Tier C kicks in around 30+ stores where the system is genuinely business-critical.

Feature change requests & emergency support

3-year total cost of ownership

A realistic projection assuming the Summerfield team grows roughly along the brief\'s scale plan (5 → ~12 stores by Y2 → ~25 stores by Y3). Hosting scales with store count; maintenance moves up from warranty (free) to Tier B (recommended) once the warranty ends.

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

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

🟢 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