Healthy School Lunch ordering platform
New Zealand
Re: MoE Healthy School Lunch Programme extension
muhammadasim@codeaza.org · codeaza.com
All amounts in NZD
The scope document supersedes the July requirements list. It describes a national, government-scale platform — parents pre-ordering funded lunches in bulk across all public schools, integrated with menus, dietary rules, delivery and production.
We recommend proving the platform on a fixed-price pilot first — 4 schools, ~1,200 students, funded lunches only, no payments — then scaling to the full national build once the model is validated. Privacy Act compliance, encrypted data and role-based access are built in from the first record; PCI genuinely waits until payments are introduced. The figures below keep the pilot, the national build and ongoing support cleanly separate.
The Full Pilot delivers every item in the document not marked "future state," across four build stages:
Discovery, architecture & design sign-off
Compressed — we already hold the scope document. Lock the data model, ordering-rules taxonomy, school-selection model and target architecture.
- Ordering-rules and menu-cycle model
- School-selection model (single-site vs per-school)
- Target architecture, security & data-handling plan
- UAT plan and acceptance criteria
Core build — portals, menu & ordering
Parent, school-admin, programme-admin and operations portals; menu management with year-level segmentation and rotating cycles; bulk term ordering with absence edits; dietary/allergy engine; email + SMS.
- Auth: email/password + Google & Apple sign-in, email verification & password reset
- Parent + child management, class lists alongside student lists, school database & settings
- School admins placing & editing orders on behalf of a parent/student (low-digital-access schools)
- Menu mgmt (Yrs 0–3 / 4–8 / 9–13, up to 3× options/day) with product fields: nutritional info, ingredients, in-stock / out-of-stock toggle
- Bulk term ordering, absence edits, quick reorder
- Dietary & allergy engine — all filters incl. Halal, all 8 listed allergens — auto-hide of conflicts
- Notifications: account-creation, order confirmations & reminders (email); cut-off reminders & alerts (SMS)
Ops, rules engine & QA hardening
The operations/production layer, configurable rules engine, full reporting, and the security hardening that makes it launch-ready.
- Operations portal: production planning, manifests, run sheets, wastage
- Admin dashboard tiles: total orders, active schools, suppliers, students, upcoming production volumes
- Configurable ordering rules engine (cut-offs)
- Reporting cuts: by student / school / region / family / meal type, plus meals produced, meals delivered, menu-item ranking
- Privacy Act, encryption & RBAC hardening
UAT, data load & launch
User acceptance testing, defect resolution, loading of the 4 pilot schools + menus, and go-live readiness ahead of Term 4.
- UAT support + defect resolution
- Load 4 schools + term menus (or CSV-roster fallback)
- Production deploy on AWS Sydney
- Go-live readiness sign-off
Security from day one: NZ Privacy Act compliance, encrypted personal data (at rest & in transit), role-based access control. PCI deferred — no payments in the pilot.
Term 4 opens Mon 12 Oct 2026 and parents order beforehand, so Fri 25 Sep is the delivery date the whole engagement hangs on — we accept it as a delivery obligation. A 10 Aug start is 6.5 working weeks with a dedicated 3-person squad plus founder oversight, and sits inside our own latest-safe green-light window.
Two hard sequences on the client side: (1) the data processing agreement is signed before we touch any real student data, including UAT and data load; (2) school + menu content, plus Apple/Google developer accounts and the Twilio NZ sender-ID, ready by ~15 Sep. A slip on either moves the load window, not the build.
All-in fixed price of $35,000 — 3 months' post-go-live engineering support (Oct–Dec 2026) is included, not billed separately. A $5,000 project fee (payable within 7 days of signing) secures the start date; the $30,000 balance splits across the core-portals milestone (~11 Sep) and final acceptance (25 Sep). Invoiced against milestones, 14-day terms. Cloud hosting and third-party tooling remain billed at cost (see below).
Band only — scoped properly after the pilot, which becomes the production foundation. Final figure depends on true concurrency, data-residency and integration phasing.
Infrastructure & tooling billed separately, at cost:
• Hosting: AWS Sydney (ap-southeast-2), ~NZD $1,000/mo
• Monitoring tooling (Grafana + Sentry): ~NZD $100–$150/mo
• SMS via Twilio: 2,000/mo included, then ~$0.12/SMS
These accounts (AWS, Grafana/Sentry, Twilio) are owned and paid directly by WeTalk.ai; Codeaza sets them up and operates them on your behalf.
Hosting — billed separately, at cost: AWS Sydney (multi-AZ + DR), ~NZD $2,000–$3,000/mo, scales with term-ordering peaks.
Monitoring tooling (Grafana + Sentry): at cost, scales with volume.
The 3-month pilot support is bundled into the fixed $35,000 — no monthly support fee during Oct–Dec 2026. Cloud hosting and tooling are billed at cost throughout. If a strict NZ data-residency mandate applies we would host on a NZ provider (e.g. Catalyst Cloud) — this changes the hosting figure. Please flag if required.
A focused 3-person squad, with founder-level review layered on top — right-sized to the fixed price and the 25 Sep date.
Validity. This quotation is open for acceptance for 30 days from the issue date and is superseded by any subsequent written quotation.
Intellectual property. All source code, models and documentation in the delivered platform are owned by WeTalk.ai Limited on final payment. Codeaza retains only its pre-existing, non-client-specific tooling and frameworks. This basis does not change the figures quoted.
Delivery date. On a green-light by Mon 10 Aug 2026, go-live by Fri 25 Sep 2026 is accepted as a delivery obligation — the platform live, tested and loaded with the four schools and their menus — subject to a frozen scope and the client-side dependencies dated above.
Defect vs support. A defect is not support: anything that does not work as the scope document specifies is incomplete delivery and is fixed at no cost. Support covers monitoring, backups and keeping the platform running; new features are scoped and quoted separately.
Change control. Scope changes are estimated in writing and take effect only on written approval by both parties. The pilot is priced on a frozen scope.
Handover. At final acceptance we deliver a handover pack — source code, documentation, deployment runbook and a handover session.
Non-circumvention. A mutual non-circumvention clause applies both ways, to be recorded in the agreement.
Confidentiality. Both parties treat commercial and technical information exchanged as confidential under the executed NDA.
Data handling & DPA. Children's personal data is processed under NZ Privacy Act obligations, encrypted at rest and in transit, on AWS Sydney (or a NZ provider if residency is mandated). A data processing agreement is signed before any real student data is touched, including UAT and the data load.
Liability. Codeaza's aggregate liability is limited to the fees paid under this engagement. Neither party is liable for indirect or consequential loss.