This backlog describes the full production platform NutriSync is being built toward: a scalable containerized backend, a secure zone for biometric and health data, consent captured everywhere data is collected, health and wearable connectors, a single unified web entry point, and an internal admin/MIS plus a protected business-case site.
The important context, as of July 2026: the product is already live and operational on Supabase (EU). Mobile and web are both shipping, both auto-deploy on every push, and the marketing and business-case surfaces are public. This backlog therefore reads less like a from-scratch plan and more like a map from where we are today (a fast Phase-1 stack on Supabase) to where we go for B2B scale (AWS core behind Cloudflare). Each epic below carries an explicit current status so investors and builders can see at a glance what is done, what is partial, and what is deliberately deferred.
Legend — Priority: P0 (MVP/launch-blocking) · P1 (fast-follow) · P2 (scale). Estimate: T-shirt (S ≤3d, M ≤1.5wk, L ≤3wk, XL >3wk).
Recommendation: AWS as the primary cloud, with Cloudflare at the edge in front of it. Use Google Cloud only if the team's deep expertise is there.
Think of it as a layered building: Cloudflare is the security gatehouse and lobby (CDN, WAF, DDoS, bot management, DNS) that every visitor passes through; AWS is the secured building behind it where the regulated data lives in a locked, windowless basement (private subnets + encrypted databases). They are complementary, not either/or.
Why AWS is the core, specifically for NutriSync:
| Need | Why AWS wins for this product |
|---|---|
| Swiss/EU data residency | AWS has a Zurich region (eu-central-2) plus Frankfurt/Ireland/Paris/Spain. Switzerland is a launch market and menstrual/health data is special-category — keeping it in-country is a strong trust + compliance story. |
| Regulated health data | Mature GDPR + Swiss FADP posture, HIPAA-eligible services, KMS envelope encryption, Nitro isolation, fine-grained IAM, dedicated VPC private subnets, audit via CloudTrail. |
| Containers + scale | ECS Fargate (serverless containers, simplest) or EKS (Kubernetes when needed), autoscaling, Aurora Postgres in private subnets. |
| Breadth | Everything in one place: managed Postgres, queues (SQS), streams (Kinesis), secrets, observability — fewer vendors for a lean team. |
Why not the others as the primary: - Cloudflare is best-in-class at the edge (CDN, WAF, DDoS, Workers, R2, Zero Trust access) and we already use it today for hosting — but it is not the right home for a regulated relational health-data store with private-subnet isolation. Keep it as the front door and for static hosting, not the secure data zone. - Google Cloud is excellent (GKE, BigQuery, healthcare APIs) and a fine alternative — but AWS's Zurich region plus the broader managed-service surface make it the lower-risk default. Pick GCP only if the hired engineers are GCP-native.
Target architecture: User → Cloudflare (DNS, CDN, WAF, DDoS, Zero Trust for admin) → AWS ALB → ECS Fargate (API) → Aurora Postgres (private subnet, KMS-encrypted) + S3 (encrypted) + Secrets Manager.
Where we are now: Phase 1 runs on Supabase (EU) — Postgres, Auth, and Row-Level Security — chosen deliberately for speed to a working product. The AWS migration below is the target, not a gap: we move the business logic into ECS when B2B scale (employer/university/clinic contracts) demands the added isolation, control, and residency guarantees. The secure-zone principles in Epic A apply to both stacks.
| Epic | Title | Priority | Current status |
|---|---|---|---|
| A | Cloud foundation & secure landing zone | P0 | Not started — Supabase Phase 1 by design |
| B | CI/CD pipeline: GitHub → production | P0 | ✅ Done — mobile OTA + web Pages, auto-deploy on push |
| C | Scalable containerized backend | P0 | Not started — Supabase stands in for Phase 1 |
| D | Data protection, consent & compliance | P0 | ◑ Substantially done — RLS + JSON export + full account deletion (Edge Function, deployed) + cookie/consent shipped; formal consent service, retention & DPIA pending |
| E | Health & wearable connectors | P1 (roadmap 2028) | ◑ Foundation built — normalized data model + consent-gated Connected Devices UI + feature flag (OFF by default); native sync needs a dev build |
| F | Unified web entry point | P0 | ✅ Done — one site on nutrisynccollective.com (custom domain live, www→apex, Zero Trust on /hub, PWA on m.); waitlist handoff (F5) shipped 19 Jul |
| G | Web admin application (MIS / KPIs) | P1 | ◑ Phase 1 live — real KPIs (admin_kpis) + growth actuals & editable assumptions (admin_growth, 19 Jul); billing metrics wait for payments |
| H | Protected business-case site | P1 | ✅ Done — gated hub live; email whitelist removed (re-addable) |
| I | Observability, security ops & DR | P1 | Not started |
| K | Identity & Authentication (doc 28) | P1 | ✅ approved 1A·2A·3B·4B — implementation next session |
| L | Payments & Subscriptions (doc 29) | P1 | ◯ proposal ready — founder decisions + company prerequisite |
Status key: ✅ Done · ◑ Partial · ▢ Documented only · Not started.
Sign-in choice, passwordless and access assurance for the pilot and beyond. Full rationale, phasing and founder decisions in doc 28 — Identity & Authentication Proposal.
signInWithOtp) as passwordless option and recovery path. AC: OTP works on all surfaces; password stays as fallback. — GO — new users see providers/OTP first (4B).Two imposed rails (Apple/Google IAP in-app · Stripe/Paddle on web) with one source of truth. Full architecture, flows and founder decisions in doc 29.
subscriptions table + is_premium() + RLS gates + RevenueCat wiring, behind a feature flag. AC: entitlement flips end-to-end in sandbox. — pending founder GO.Current status: Not started — Supabase Phase 1 by design. Today Supabase (EU) provides Postgres, Auth, and Row-Level Security, which covers Phase-1 needs. This epic is the AWS secure landing zone we build when scale and B2B compliance obligations justify it.
Goal: a hardened, multi-environment AWS foundation with a dedicated secure zone for biometric/personal data.
dev, staging, prod, and security/audit. AC: accounts isolated; SCP guardrails deny public S3 and non-EU/CH regions; billing alerts on.terraform plan clean; environments reproducible from code.Current status: ✅ Done — both tracks live. Every push ships automatically. Think of each GitHub Action as a conveyor belt: code goes in one end, a live update comes out the other, no human hand on the lever.
githubjuanjose/nutrisync-app → GitHub Action .github/workflows/eas-update.yml → eas update --branch production (over-the-air) on every push. Secret: EXPO_TOKEN. EAS project id 3b124e7e-e7e8-43ed-a54c-b660a07109dc; app.json updates.url = https://u.expo.dev/3b124e7e-e7e8-43ed-a54c-b660a07109dc; runtimeVersion policy appVersion. Installed builds pull the OTA update on next launch.githubjuanjose/nutrisync-web → GitHub Action .github/workflows/deploy-web.yml → wrangler pages deploy publish --project-name=nutrisync-collective on every push to main. Secrets: CLOUDFLARE_API_TOKEN (a Custom token scoped Account · Cloudflare Pages · Edit — the old "Edit Cloudflare Pages" template no longer exists) and CLOUDFLARE_ACCOUNT_ID. We deliberately use the Action→wrangler direct-upload path rather than Cloudflare's built-in "Workers Builds" Git integration, which hung.The AWS-specific CI/CD items below (ECR, ECS blue/green, gated DB migrations) are the scale-up continuation of this epic and land alongside Epics A and C.
main; PRs require green CI + 1 review. — ◑ rulesets live on both repos (no force-push/delete, 19 Jul); PR-required + CI gate deferred until the GitHub org lands (Epic J).dev on merge, staging on tag, prod on manual approval (GitHub Environments); blue/green or rolling. AC: zero-downtime deploys; one-click rollback; deploy events logged. — AWS phase.Current status: Not started — Supabase stands in for Phase 1. The Supabase Postgres backend already serves the live mobile and web apps across 8 core tables plus content tables, with the CAS engine writing daily_scores in real time. This epic containerizes and hardens that backend on AWS when B2B scale requires it.
Goal: an API platform that scales from 10K to millions of users (per the GTM roadmap).
/recommendations contract (rules → ML/Apertus AI). AC: engine swappable without client changes; inputs/outputs logged (consented, de-identified).Current status: ◑ Substantially done. The P0 data-rights gaps are now closed. Row-Level Security scopes every row to auth.uid(); users export their data as JSON; and full account deletion is live — the delete-account Edge Function erases the user's data and their auth identity server-side (the service_role key stays on the server, never in the app). The cookie/consent layer is shipped too: a privacy-first web banner with essential-only defaults and granular opt-ins. What remains is governance, not code: the formal consent service (versioned, granular onboarding opt-ins — D1–D3), retention/minimization (D6), and DPIA/RoPA paperwork (D7).
Goal: biometric/menstrual/health data handled lawfully under GDPR & Swiss FADP, with consent captured everywhere data is collected.
auth.uid().Current status: ◑ Foundation built (native sync deferred). The Expo Go-safe groundwork now exists: a normalized health_signal schema plus a connected_providers table (E-P1), a consent-gated Connected Devices screen listing the top 8 (E-P3), and a provider registry. It all sits behind a feature flag that defaults OFF (EXPO_PUBLIC_FLAG_CONNECTORS), so nothing ships to current testers until a native iOS/TestFlight build. The remaining work is the native adapters — Apple Health (HealthKit) and Health Connect need a dev build, and the OAuth providers (Garmin/Fitbit/Strava/Oura/Huawei/Xiaomi) need backend workers. Each still normalizes to the common health_signal shape and is consent-gated.
The prioritized top 8 to support: Apple Health / Apple Watch, Samsung Health, Google Fit / Fitbit, Garmin, Xiaomi (Mi Fitness), Huawei Health, Oura, Strava.
Tier 1 — native phone health platforms (highest reach): - E1 (P1, L) — Apple Health (HealthKit) — steps, workouts, sleep, HR, cycle/menstrual data (iOS). AC: read selected types with user grant; background delivery; revoke handled. - E2 (P1, L) — Google Health Connect / Android (replaces Google Fit) — steps, workouts, sleep, HR. AC: Health Connect permissions; graceful when app absent. - E3 (P1, L) — Samsung Health — activity, sleep, HR (Android/Galaxy + Watch). AC: SDK integration; scoped read. - E4 (P1, M) — Huawei Health — activity, sleep, HR. AC: OAuth/SDK; scoped read. - E5 (P1, M) — Xiaomi (Mi Fitness) — activity, sleep, HR. AC: OAuth/SDK; scoped read.
Tier 2 — wearables / fitness ecosystems: - E6 (P1, L) — Garmin Connect — activity, HR, sleep, stress. AC: OAuth + webhook pull; backfill window. - E7 (P1, M) — Fitbit (Google Fit family) — steps, sleep, HR. AC: OAuth2; rate-limit aware. - E8 (P1, M) — Strava — runs/rides/activities. AC: OAuth2 + webhooks; dedup vs phone data. - E9 (P2, M) — Oura (ring) — sleep, readiness, HRV, temperature (useful for cycle phase). AC: OAuth2; temp trends mapped to cycle model. - E10 (P2, M) — Apple Watch / Wear OS companion surfacing — show phase + daily focus on-wrist. AC: complication/tile reads today's phase + focus.
Connector platform (shared):
- E-P1 (P1, L) — Connector framework: normalized health_signal schema, per-provider adapters, token vault, incremental sync + backfill, dedup. AC: adding a provider = new adapter only; conflicts resolved by priority rules.
- E-P2 (P1, M) — Sync orchestration via SQS workers + webhooks; retry/backoff; per-provider observability. AC: failed syncs alert; per-user sync status visible.
- E-P3 (P1, S) — Consent + revoke wiring (depends D3): disconnect purges provider tokens and optionally data. AC: revoke stops sync in < 1 min; tokens deleted.
Current status: ✅ Done. NutriSync ships as one site on the Cloudflare Pages project nutrisync-collective: the marketing site at the root, the transactional web app at /app.html, and the gated investor/builder hub reached from the footer "Team access." The web app is the Claude Design bundle genuinely stitched to the same Supabase backend — real sign-up/log-in, session routing (no session → login · session without a cycle → onboarding · else → home), reading and writing all 8 tables, and the same 5-component CAS writing daily_scores. In-app JSON export and delete work here too. The anon key is baked in and is public and safe (RLS scopes every row).
Live URLs:
- Marketing (root): https://nutrisync-collective.pages.dev
- Web app: https://nutrisync-collective.pages.dev/app.html
- Gated hub: footer Team access, code 123456.
Goal: the commercial/marketing site and the transactional web app are one application behind a single entry point that routes anonymous visitors to marketing and authenticated users to the app.
nutrisync-collective).public.waitlist table (RLS-private, anon-insert), the marketing-site + newsletter fields now persist signups (tagged by source), ~140 legacy signups migrated from an old Supabase project, and a Founders' Waitlist dashboard in the Builders hub with full CRUD + CSV export (admin-gated, with undo). 19 Jul: handoff shipped — converted_at + auth trigger + backfill; dashboard shows an App-user column and conversion stats. ✅ done.nutrisynccollective.com) instead of *.pages.dev: Cloudflare Pages → Custom domains → Add, point the domain's DNS at Pages, force HTTPS, and redirect the pages.dev URL to it. AC: site served on the branded domain with valid TLS; both apex and www resolve; old URL 301s to the new one. — ✅ DONE (18 Jul) — live on https://nutrisynccollective.com with TLS, www→apex 301, pages.dev canonical-bounced on hub routes.Cleanup note: the account still contains stale artifacts — an old nutrisync-web.pages.dev project and a broken nutrisync Worker. Neither is in use; both are safely deletable.
Current status: ◑ Live KPIs wired. The console now pulls real aggregates — Total Users and DAU/WAU/MAU — through an admin-gated, aggregate-only admin_kpis() function (SECURITY DEFINER; returns counts, never PII; refuses non-admins). An admins allowlist plus an auto-promote trigger manage access. A second admin surface is now live too: the Founders' Waitlist dashboard (Builders hub) — searchable/sortable signup list with per-source counts, full CRUD (add/edit/delete with confirm + undo) and CSV export, admin-gated via admin_waitlist_crud.sql RLS policies. Business/financial figures (MRR, subscriptions, revenue) stay modelled and are clearly labelled, because there is no billing system yet to read from — they become live via the same pattern once payments exist. Remaining: role tiers, Cloudflare Zero Trust gating on the admin path, and connector/ops panels.
Goal: an internal admin app (Cloudflare Zero-Trust protected) to run the business — access, subscriptions, and the business case.
admin_growth (12-month users/waitlist, conversion %) + editable assumptions with 12-month projection vs plan. Phase 2 (revenue/cost actuals) waits for payments (Stripe/RevenueCat).Current status: ✅ Done. The gated investor/builder hub is live inside nutrisync-collective, reached from the footer "Team access" with code 123456. The earlier Cloudflare Access email whitelist has been removed, so the site is publicly reachable today; it can be re-gated at any time via Cloudflare Zero Trust → Access when sharing shifts to a controlled investor list.
Goal: an access-controlled site presenting the full business case, pitch, and documentation for investors/advisors/team.
Current status: Not started. Formal observability, security-ops tooling, and disaster-recovery drills land with the AWS migration; Phase-1 relies on Supabase's managed backups and platform monitoring.
The picture has changed since the original plan: Wave 1 is largely already delivered on the Supabase Phase-1 stack. What was once "stand up CI/CD and one unified site" is done; the near-term work is getting the app into testers' hands, and the AWS migration is now a scale-driven wave rather than a launch prerequisite.
eas build --profile preview --platform android — no paid account needed) and iOS TestFlight once the paid Apple Developer Program is enrolled. Close the Epic D gaps: the service-role Edge Function for full auth-record deletion and the cookie/consent layer (D8). Wire the admin console to live data (Epic G). Harden branch protection (B1).service_role key must never ship client-side.The launch foundation (Epics B, F, H) is already live, so the immediate, highest-leverage step is getting the app onto testers' devices:
eas build --profile preview --platform android → shareable download link/QR. Install once; thereafter every GitHub push reaches testers over-the-air via the Epic B mobile pipeline.eas build --platform ios --profile production → eas submit --platform ios --latest → TestFlight (External testing = one-time Beta App Review). Bundle id com.nutrisync.app; export-compliance is pre-answered.The AWS migration (Epics A/C/I) is the subsequent step, triggered when B2B scale demands it — not a prerequisite for the current pilot.
Alongside the infrastructure epics above, these product tracks sit on the roadmap. Status as of July 2026:
| Track | Status | Notes |
|---|---|---|
| Waitlist & signups | ✅ Done (capture + admin) | Live public.waitlist table; marketing + newsletter capture; ~140 legacy signups migrated; Founders' CRUD dashboard (search/filter/export/undo) in the Builders hub. F5 handoff shipped 19 Jul (auto converted_at via auth trigger + dashboard column). |
| DB change safety | ✅ Done | Backup-first runbook (11-DB-Changes-Runbook) + in-dashboard undo; every data/schema SQL now leads with a backup and ends with a verify step. |
| Bilingual EN/ES | ✅ Done (web + mobile) | Decoupled i18n/ catalogs; language selector on both surfaces; canonical values stay English. Founders review Spanish wording via the Translations page in the Builders hub, then export es.json. |
| Multilingual — 14 languages | ◑ 7 of 14 live | Live (web app + mobile): EN, ES, FR, DE, IT, NL, EL. Marketing translated: EN, ES, FR, DE. Pending packs: CA, EU, GL, VA, Aranés, ZH, JA (+ IT/NL/EL marketing). Selector = ISO-code pills [EN]+[OS/ES] + dropdown (web) — mobile shows endonyms (consistency TBD). MT first pass → native review (locked): European+East-Asian from English (Google/DeepL); Iberian from Spanish via Apertium; CJK font needed on web for ZH/JA. Mobile bundles each app translation as it ships (mob.* falls back to English until translated). See Design Brief §6. |
| Localization workflow | ✅ Done | Founder-editable Translations review tool; integrate.py keeps web + mobile catalogs in sync on each Design export. |
| Custom domain (F7) | ✅ Done (18 Jul) | Publish on the branded NutriSync domain (Cloudflare Pages → Custom domains). ~15-min DNS task. |
| Monetization / subscriptions (WF-10) | ⬜ Not built | Billing system (e.g. Stripe) → premium gating, real MRR/churn in the admin console. Prerequisite for the "· model" KPIs going live. |
| Community (WF-7) | ⬜ Not built | Feed, cycle-status sharing, streaks — the Community Privacy controls already exist in-app as the settings surface. |
| Native wearable sync (Epic E adapters) | ⬜ Deferred | Apple Health / Health Connect need a native dev build; foundation + consent UI already shipped behind the connectors flag. |
Sequencing view: bilingual and the localization workflow are done. The next product build with real revenue impact is monetization (it also unblocks the live admin financial KPIs). Community and native wearables are later-stage. Custom domain is a quick your-side task, independent of all of the above.
Move all infrastructure off personal accounts: Google Workspace on the domain, GitHub organisation + transfer of nutrisync-app/nutrisync-web (with Cloudflare Pages re-connection), company-held Cloudflare/Supabase/Expo access, Organization enrollment for Apple + company Play Console, IONOS under company identity, team password vault, 3+1 admin model everywhere. Full phased task list, per-platform explainers and access matrix: doc 19 · Corporate Migration Plan (EN+ES).
Pre-launch: payments (Stripe/RevenueCat), observability (Sentry, uptime, alerting), security hardening (WAF/Turnstile, quotas, secrets rotation, backup RESTORE drill + PITR), staging env + CI, store release pipeline, compliance ops (DPIA, DPAs, retention, delete E2E), support ops. AWS migration is trigger-based (latency/plan-ceiling/cost/enterprise), with the Supabase-dedicated intermediate step evaluated first. Full task list: doc 19 · Appendix B.