Everything the company runs on, moved from personal accounts to NutriSync-owned accounts, with the 3 founders + Juanjo (3+1) holding admin access everywhere. English first, Español después.
Today the platform runs on personal accounts (GitHub githubjuanjose, personal Cloudflare/Supabase/Expo logins). That works for a prototype; for a company it is a bus-factor and ownership risk: if one person loses access, the company loses its infrastructure. Goal: every account owned by the company, every credential in a shared vault, 3+1 admins everywhere, personal accounts out of the critical path.
| Platform | What it is for us | Why it matters |
|---|---|---|
| GitHub | Source code home: nutrisync-app (iOS/Android/PWA source) and nutrisync-web (marketing+webapp+hub). Pushing to nutrisync-web triggers the web deploy. main is protected on both. |
The product IS this code. Losing it = losing the product. It is also the code's backup. |
| Cloudflare | Four jobs: (1) DNS for nutrisynccollective.com; (2) Pages hosts the web (nutrisync-collective) and the PWA (nutrisync-m) with full deployment history and one-click rollback; (3) Zero Trust Access guards /hub/* (founder email + PIN); (4) SSL, caching, www-redirect. |
The front door of everything public, and the lock on everything private. |
| Supabase | The backend: PostgreSQL database (EU), user authentication (incl. email verification), Row-Level Security so each user only reads her own health data, and the RPCs (recommendations engine, waitlist counter, admin KPIs, feedback). | Holds the special-category health data — the crown jewels, GDPR-wise. |
| Expo / EAS | Builds the native iOS/Android binaries and ships OTA updates: JS-level app updates reach phones in minutes without app-store review. Also the base of the PWA build. | Our 6-updates-in-a-day cadence exists because of OTA. |
Mobile PWA (m.nutrisynccollective.com) |
The 4th surface: the native app itself compiled to web (react-native-web) and served as an installable Progressive Web App — "Add to Home Screen", full-screen, no app store. Lives on the Pages project nutrisync-m; rebuilt from the app source with one command, so it always matches the native version. |
App-like experience with zero store friction — the footer QR points here. Our fastest distribution channel while store enrollment is pending. |
| Apple / TestFlight | Distributes the iOS app to testers (and later the App Store). Enrollment pending — enroll as an Organization (needs the legal entity + D-U-N-S number), so the store listing says NutriSync, not a person. | Only path onto iPhones. |
| Google Play Console | Same for Android (internal testing → production). Create as a company account. | Only path onto Android at scale. |
Working folder (NutriSync/) |
The operational file system: builds to deploy (inbox/), every shipped version (releases/ = rollback points), design packs, feedback rounds, SQL migration history, deploy tools. |
The company's operational memory; backed up to Drive. |
| IONOS | The domain registrar: where nutrisynccollective.com is registered and renewed, and where the mailboxes currently live. DNS was delegated to Cloudflare, but IONOS still owns the registration — if it lapses, the domain (and every URL, email and QR pointing at it) dies. |
Registration + renewal + today's mail hosting. Must be company-owned with auto-renew. |
| Google (Workspace) | To be created: company Google account — email on the domain, shared Drive (backup target for the working folder), shared calendar, and the identity anchor for other services. | One identity to rule the logins. |
| Password vault (to be chosen) | Team password manager (1Password/Bitwarden): every shared credential, API key, 2FA recovery code. | Without it, "3+1 admins" degenerates into credentials in chats. |
releases/ in the working folder: every app zip since v0.9.0, every deployed web zip, PWA dists. Never deleted.repos/), to move to the company shared Drive in P1.P0 · Prerequisites (founders)
1. Confirm the legal entity data (name, CIF) — needed for Google Workspace billing, Apple D-U-N-S and Play Console.
2. Decide the 4 admin identities: pgonzalez@, lcebrian@, mgarzon@, jcebrian@ (or equivalents) on the domain.
3. Pick a team password manager (1Password Business / Bitwarden Teams) — every shared credential, 2FA recovery code and API key lives there. This is the single most valuable security upgrade of the whole plan.
P1 · Google Workspace (company Google account)
4. Create Google Workspace on nutrisynccollective.com (Business Starter is enough to start).
5. Create the 4 user accounts + contact@ (as user or alias) + admin@ (alias).
6. ⚠ Email hosting decision: mailboxes currently live at IONOS. Moving mail to Google = switching MX records in Cloudflare DNS + migrating existing mail. Plan a low-traffic window; verify contact@ delivery after (same test as the domain migration). Alternative: keep IONOS mail and use Workspace only for Drive/identity — decide consciously.
7. Enforce 2FA for all Workspace users.
8. Create the shared Drive "NutriSync Ops"; re-point the working-folder backup there.
P2 · GitHub organisation
9. Create org (e.g. nutrisync-collective); add the 4 as Owners; enforce 2FA at org level.
10. Transfer nutrisync-app and nutrisync-web from githubjuanjose to the org (Settings → Transfer ownership). GitHub keeps redirects, but:
11. Re-point clone remotes: git remote set-url origin <new-url> in repos/appdev and repos/webdeploy.
12. Re-connect Cloudflare Pages to the transferred nutrisync-web repo (the GitHub App integration does not follow transfers automatically — reinstall the Cloudflare Pages GitHub App on the org and re-link the project). Verify with a test deploy.
13. Re-create the protect-main rulesets on both repos (verify they survived the transfer; recreate if not).
P3 · Cloudflare 14. Change the account email to a company address (or create a company account and move the domain + both Pages projects + Zero Trust — bigger job; changing the email on the existing account is the pragmatic path). 15. Add the other 3 as account members with Administrator role (Manage Account → Members). 16. Store the account credentials + 2FA recovery in the vault. Verify Zero Trust, both Pages projects and DNS untouched.
P4 · Supabase
17. In the organisation settings: invite the 4 company emails (Owner/Admin roles), then transfer organisation ownership to a company identity.
18. Enforce 2FA; store the database password + service_role key only in the vault (service_role never leaves it).
19. Review public.admins allowlist — add the founders' app-login UUIDs so KPIs/feedback work for them.
P5 · Expo / EAS
20. Create an Expo organisation account for NutriSync; invite the 4.
21. Transfer the nutrisync-mobile project to the org (Expo supports project transfer); update owner in app.json; verify eas update still publishes to the same channel (test OTA).
22. Create a robot token for future CI instead of personal login.
P6 · Stores (pragmatic two-step, since the legal entity is still being formed) 23. Now: Apple Developer as Individual (already paid, verification pending — up to 48h) → unblocks development + TestFlight immediately. Later: once the company + D-U-N-S exist, request the Individual → Organization conversion via Apple Developer Support (account, apps and testers are preserved; the listing name changes to NutriSync). 24. Google Play Console: same pattern — individual account now if needed for internal testing; when the company exists, create the company account and use Play's app transfer (Play does not convert accounts; it transfers apps between them).
P7 · Domain registrar & the rest 25. IONOS account → company email + credentials to the vault (it remains the registrar even though DNS is at Cloudflare); make sure domain auto-renews with a company card. 26. When the newsletter/email provider is chosen (Resend/Mailchimp): create under company account from day one. 27. Figma: Design's project under a NutriSync team with founder access (coordinate with Design).
P8 · Verification (after each phase — nothing is "done" until this passes)
28. Web deploy end-to-end · OTA deploy end-to-end · PWA build+deploy · hub Access login · contact@ receives mail · backups landing in the shared Drive · all 4 can log into all consoles · vault contains every credential.
Juanjo holds the technical super-admin role on an interim basis, until a CTO (or designated super-admin) is appointed — at which point these roles transfer to that person following the same handover checklist as this migration (P8 verification included). The founders' access is permanent by design.
| Platform | Pilar · Lucía · María Paula | Interim super-admin (Juanjo → future CTO) |
|---|---|---|
| Google Workspace | Admin | Super Admin |
| GitHub org | Owner | Owner |
| Cloudflare | Administrator | Super Admin (account holder) |
| Supabase | Owner/Admin | Owner |
| Expo/EAS | Admin | Owner |
| Apple / Play | Admin/App Manager | Account Holder / Admin |
| Password vault | Member (full) | Admin |
Built (live today): 4 surfaces (web, PWA, iOS, Android OTA) on one Supabase backend · content DB (153 foods / 48 movements / 100 tips) + segment-aware recommendations engine · CAS scoring · full app feature set through 3 founder-feedback rounds (all 56 Round-3 items closed) · gated Builders/Investors hub with real Access login · live waitlist counter · versioned releases with rollback · documented ops (docs 11, 14, 18).
Missing (known, queued): store distribution (TestFlight/Play — blocked on enrollment) · lawyer-approved privacy/terms texts (drafts ready) · marketing video · remaining language packs (7 of 14 live; CA/EU/GL/VA/Aranés/ZH/JA pending + CJK web font) and onboarding steps i18n (F1) · payments (€4.99/employer model → Stripe or RevenueCat, not started) · error monitoring (Sentry) and product analytics (opt-in) · email provider for newsletter · consent service (versioned granular scopes with audit trail — D1–D3/D6, beyond today's checkbox) · wearable/health connectors (schema + Connected Devices screen built; native Apple Health/Google Fit sync pending — Epic E) · push notifications (Notification Center screen exists; delivery infra pending) · waitlist→onboarding auto-handoff (F5) · admin business-case tracker live wiring (G3) · community features (WF-7 — privacy controls already shipped) · multimodal search (backlog).
Changes at full production: this migration executed (company-owned everything) · store binaries via EAS Build instead of dev-tunnel testing · payment processing + subscription entitlements in-app · monitoring/alerting + on-call habits · rate limiting and abuse protection on public endpoints · DPIA + registro de tratamientos completed with the lawyer · scale review of Supabase plan (and the doc-02 AWS scale-up target if growth demands it) · Design→Engineering handoff cadence formalised on org repos.
Hoy la plataforma corre sobre cuentas personales (GitHub githubjuanjose, logins personales de Cloudflare/Supabase/Expo). Para un prototipo vale; para una empresa es un riesgo de propiedad y de "factor autobús": si una persona pierde el acceso, la empresa pierde su infraestructura. Objetivo: cada cuenta a nombre de la empresa, cada credencial en un gestor compartido, 3+1 administradores en todo, y las cuentas personales fuera del camino crítico.
| Plataforma | Qué es para nosotros | Por qué importa |
|---|---|---|
| GitHub | Casa del código: nutrisync-app (fuente de iOS/Android/PWA) y nutrisync-web (marketing+webapp+hub). Un push a nutrisync-web dispara el despliegue web. main protegida en ambos. |
El producto ES este código. Perderlo = perder el producto. Además es el backup del código. |
| Cloudflare | Cuatro funciones: (1) DNS de nutrisynccollective.com; (2) Pages aloja la web (nutrisync-collective) y la PWA (nutrisync-m) con historial completo de despliegues y rollback de un clic; (3) Zero Trust Access protege /hub/* (email de founder + PIN); (4) SSL, caché, redirección www. |
La puerta de todo lo público y el candado de todo lo privado. |
| Supabase | El backend: base de datos PostgreSQL (UE), autenticación de usuarias (incl. verificación de email), Row-Level Security para que cada usuaria solo lea sus propios datos de salud, y los RPCs (motor de recomendaciones, contador de waitlist, KPIs, feedback). | Guarda los datos de salud de categoría especial — las joyas de la corona a efectos RGPD. |
| Expo / EAS | Compila los binarios nativos iOS/Android y publica actualizaciones OTA: los cambios de la app llegan a los móviles en minutos sin pasar por revisión de tienda. También es la base de la build de la PWA. | Nuestra cadencia de 6 actualizaciones en un día existe gracias al OTA. |
PWA móvil (m.nutrisynccollective.com) |
La 4ª superficie: la propia app nativa compilada a web (react-native-web) y servida como Progressive Web App instalable — "Añadir a pantalla de inicio", pantalla completa, sin tiendas. Vive en el proyecto Pages nutrisync-m; se reconstruye desde el código de la app con un comando, así que siempre va a la par de la versión nativa. |
Experiencia de app sin fricción de tiendas — el QR del footer apunta aquí. Nuestro canal de distribución más rápido mientras el alta en las tiendas está pendiente. |
| Apple / TestFlight | Distribuye la app iOS a testers (y luego al App Store). Alta pendiente — daros de alta como Organización (requiere entidad legal + número D-U-N-S) para que la ficha diga NutriSync y no una persona. | Único camino a los iPhone. |
| Google Play Console | Lo mismo para Android (testing interno → producción). Crear como cuenta de empresa. | Único camino a Android a escala. |
Carpeta de trabajo (NutriSync/) |
El sistema de ficheros operativo: builds por desplegar (inbox/), cada versión publicada (releases/ = puntos de rollback), packs de diseño, rondas de feedback, historial SQL, herramientas de despliegue. |
La memoria operativa de la empresa; con backup en Drive. |
| IONOS | El registrador del dominio: donde nutrisynccollective.com está registrado y se renueva, y donde viven hoy los buzones de correo. El DNS se delegó a Cloudflare, pero el registro sigue siendo de IONOS — si caduca, muere el dominio (y toda URL, email y QR que apunte a él). |
Registro + renovación + correo actual. Debe ser de la empresa y con autorrenovación. |
| Google (Workspace) | Por crear: la cuenta Google de empresa — correo en el dominio, Drive compartido (destino del backup de la carpeta), calendario, y el ancla de identidad del resto de servicios. | Una identidad para gobernar todos los logins. |
| Gestor de contraseñas (por elegir) | Gestor de equipo (1Password/Bitwarden): toda credencial compartida, clave API y código de recuperación 2FA. | Sin él, el "3+1 admins" degenera en credenciales por chats. |
releases/ en la carpeta de trabajo: cada zip de app desde v0.9.0, cada web desplegada, los dist de la PWA. No se borra nada.repos/), a mover al Drive compartido de empresa en la fase P1.P0 · Prerrequisitos (founders)
1. Confirmar datos de la entidad legal (denominación, CIF) — hacen falta para la facturación de Workspace, el D-U-N-S de Apple y Play Console.
2. Decidir las 4 identidades admin: pgonzalez@, lcebrian@, mgarzon@, jcebrian@ (o equivalentes) en el dominio.
3. Elegir gestor de contraseñas de equipo (1Password Business / Bitwarden Teams) — toda credencial compartida, código de recuperación 2FA y clave API vive ahí. Es la mejora de seguridad más valiosa de todo el plan.
P1 · Google Workspace (cuenta Google de empresa)
4. Crear Workspace sobre nutrisynccollective.com (Business Starter basta para empezar).
5. Crear los 4 usuarios + contact@ (usuario o alias) + alias admin@.
6. ⚠ Decisión de correo: los buzones viven hoy en IONOS. Mover el correo a Google = cambiar los registros MX en Cloudflare + migrar el correo existente. Planificarlo en ventana tranquila y verificar la entrega a contact@ después (mismo test que en la migración del dominio). Alternativa: mantener el correo en IONOS y usar Workspace solo para Drive/identidad — decidirlo conscientemente.
7. Forzar 2FA a todos los usuarios de Workspace.
8. Crear el Drive compartido "NutriSync Ops" y apuntar allí el backup de la carpeta de trabajo.
P2 · Organización de GitHub
9. Crear la organización (p. ej. nutrisync-collective); añadir a los 4 como Owners; exigir 2FA a nivel de organización.
10. Transferir nutrisync-app y nutrisync-web desde githubjuanjose a la organización (Settings → Transfer ownership). GitHub mantiene redirecciones, pero:
11. Re-apuntar los remotos de los clones: git remote set-url origin <url-nueva> en repos/appdev y repos/webdeploy.
12. Reconectar Cloudflare Pages al repo transferido (la integración GitHub App no sigue a las transferencias: reinstalar la app de Cloudflare Pages en la organización y re-vincular el proyecto). Verificar con un deploy de prueba.
13. Re-crear los rulesets protect-main en ambos repos (comprobar si sobrevivieron a la transferencia; recrearlos si no).
P3 · Cloudflare 14. Cambiar el email de la cuenta a una dirección de empresa (o crear cuenta de empresa y mover dominio + los dos proyectos Pages + Zero Trust — trabajo mayor; cambiar el email de la cuenta actual es el camino pragmático). 15. Añadir a las otras 3 como members con rol Administrator (Manage Account → Members). 16. Credenciales + recuperación 2FA al gestor. Verificar que Zero Trust, ambos Pages y el DNS siguen intactos.
P4 · Supabase
17. En la organización: invitar los 4 emails de empresa (roles Owner/Admin) y transferir la propiedad de la organización a una identidad de empresa.
18. Forzar 2FA; contraseña de la base de datos y clave service_role solo en el gestor (la service_role no sale de ahí jamás).
19. Revisar la allowlist public.admins — añadir los UUID de login de las founders para que KPIs/feedback les funcionen.
P5 · Expo / EAS
20. Crear cuenta de organización en Expo; invitar a los 4.
21. Transferir el proyecto nutrisync-mobile a la organización; actualizar owner en app.json; verificar que eas update sigue publicando al mismo canal (probar un OTA).
22. Crear un token robot para el futuro CI en lugar de login personal.
P6 · Tiendas (dos pasos pragmáticos, dado que la sociedad está en formación) 23. Ahora: Apple Developer como Individual (ya pagado, verificación pendiente — hasta 48h) → desbloquea desarrollo + TestFlight de inmediato. Después: cuando existan la sociedad y su D-U-N-S, solicitar a Apple Developer Support la conversión Individual → Organización (se conservan cuenta, apps y testers; la ficha pasa a decir NutriSync). 24. Google Play Console: mismo patrón — cuenta individual ahora si hace falta para testing interno; con la sociedad creada, abrir la cuenta de empresa y usar la transferencia de apps de Play (Play no convierte cuentas; transfiere apps entre ellas).
P7 · Registrador del dominio y resto 25. Cuenta de IONOS → email de empresa + credenciales al gestor (sigue siendo el registrador aunque el DNS esté en Cloudflare); asegurar autorrenovación del dominio con tarjeta de empresa. 26. Cuando se elija proveedor de newsletter (Resend/Mailchimp): crearlo bajo cuenta de empresa desde el día uno. 27. Figma: el proyecto de Diseño bajo un team NutriSync con acceso de las founders (coordinar con Diseño).
P8 · Verificación (tras cada fase — nada está "hecho" hasta que esto pasa)
28. Deploy web completo · deploy OTA completo · build+deploy de PWA · login de Access al hub · contact@ recibe correo · los backups llegan al Drive compartido · los 4 entran en todas las consolas · el gestor contiene todas las credenciales.
Juanjo ejerce el rol de super-admin técnico con carácter interino, hasta que se nombre un CTO (o super-admin designado) — en ese momento estos roles se transfieren a esa persona siguiendo la misma checklist de traspaso que esta migración (verificación P8 incluida). El acceso de las founders es permanente por diseño.
| Plataforma | Pilar · Lucía · María Paula | Super-admin interino (Juanjo → futuro CTO) |
|---|---|---|
| Google Workspace | Admin | Super Admin |
| Organización GitHub | Owner | Owner |
| Cloudflare | Administrator | Super Admin (titular) |
| Supabase | Owner/Admin | Owner |
| Expo/EAS | Admin | Owner |
| Apple / Play | Admin/App Manager | Account Holder / Admin |
| Gestor de contraseñas | Miembro (completo) | Admin |
Construido (vivo hoy): 4 superficies (web, PWA, iOS, Android OTA) sobre un único backend Supabase · base de contenidos (153 alimentos / 48 movimientos / 100 tips) + motor de recomendaciones por segmento · scoring CAS · funcionalidad completa de la app tras 3 rondas de feedback de founders (los 56 puntos de la Ronda 3 cerrados) · hub Builders/Investors con login real de Access · contador de waitlist en vivo · versiones archivadas con rollback · operación documentada (docs 11, 14, 18).
Pendiente (conocido, en cola): distribución en tiendas (TestFlight/Play — bloqueado por el alta) · textos legales aprobados por abogado (borradores listos) · vídeo de marketing · packs de idioma restantes (7 de 14 vivos; pendientes CA/EU/GL/VA/Aranés/ZH/JA + fuente CJK en web) e i18n del onboarding (F1) · pagos (modelo 4,99€/employer → Stripe o RevenueCat, sin empezar) · monitorización de errores (Sentry) y analítica de producto (opt-in) · proveedor de email para la newsletter · servicio de consentimiento (scopes granulares versionados con traza de auditoría — D1–D3/D6, más allá del checkbox actual) · conectores wearables/salud (esquema + pantalla Connected Devices construidos; sincronización nativa Apple Health/Google Fit pendiente — Epic E) · notificaciones push (la pantalla Notification Center existe; la infraestructura de envío no) · handoff automático waitlist→onboarding (F5) · cableado en vivo del tracker de negocio del admin (G3) · funciones de comunidad (WF-7 — los controles de privacidad ya están) · búsqueda multimodal (backlog).
Cambios al pasar a producción total: esta migración ejecutada (todo propiedad de la empresa) · binarios de tienda vía EAS Build en lugar de pruebas por túnel · procesamiento de pagos y suscripciones en la app · monitorización/alertas y hábitos de guardia · rate limiting y protección anti-abuso en los endpoints públicos · DPIA + registro de tratamientos completados con el abogado · revisión de escala del plan de Supabase (y el objetivo AWS del doc 02 si el crecimiento lo exige) · cadencia Diseño→Ingeniería formalizada sobre los repos de la organización.
┌────────────────────────────────────────────┐
users ───────────► │ CLOUDFLARE (edge) │
│ DNS · SSL · www→apex 301 · cache rules │
│ ┌──────────────┐ ┌──────────────────┐ │
│ │ Pages: │ │ Pages: │ │
│ │ nutrisync- │ │ nutrisync-m │ │
│ │ collective │ │ (mobile PWA) │ │
│ │ web+app+hub │ │ m.nutrisync…com │ │
│ └──────┬───────┘ └────────┬─────────┘ │
│ │ Zero Trust Access │ │
│ │ guards /hub/* │ │
└─────────┼─────────────────────┼────────────┘
iOS app ──────┐ │ │
Android app ──┤ (EAS OTA) ▼ ▼
└──────────► ┌────────────────────────────┐
│ SUPABASE (EU) │
│ Postgres + RLS · Auth │
│ (email verification ON) │
│ RPCs: recommendations, │
│ waitlist, admin KPIs, │
│ feedback │
└────────────────────────────┘
service_role key never leaves the vault. The founders' hub sits behind Cloudflare Access (email + PIN).service_role no sale del gestor de contraseñas. El hub de founders está tras Cloudflare Access (email + PIN).(Diagrama común arriba · Detalle completo: doc 02 · Operación: doc 18)
The Supabase + Cloudflare stack comfortably serves the early-growth phase; these tasks make it production-grade. All are pre-launch work:
Payments & business 1. Payment processing for the €4.99 + employer model: Stripe (web) and/or RevenueCat (in-app subscriptions across iOS/Android/web) — entitlements table in Supabase, webhook handler, grace periods, invoices. 2. Pricing/entitlement gates in the app (free-vs-paid feature map).
Observability & alerting 3. Error monitoring: Sentry on app + web (EU data residency), release-tagged so every OTA maps to its errors. 4. Uptime monitoring on the 3 public hostnames + Supabase health; alerts to a founders channel. 5. Supabase log retention/drains; basic dashboards (signups, active users, error rate) beyond the current admin KPIs.
Security hardening 6. Rate limiting + bot protection: Cloudflare WAF rules and Turnstile on signup and waitlist; per-user quotas on write RPCs. 7. Secrets rotation + dependency/vulnerability audit (npm audit + GitHub Dependabot on the org repos). 8. Backup restore drill — actually restore a snapshot to a scratch project and verify (a backup that has never been restored is a hypothesis); enable PITR (Supabase Pro). 8b. Database in a secure zone: enable Supabase network restrictions (database reachable only from allowed IPs — direct SQL access never open to the internet), SSL enforced on every connection, encryption at rest verified, and the anon/service key pair audited (service_role vault-only). Clients keep talking ONLY through the RLS-guarded API — never to the database directly.
Release engineering 9. Staging environment: second Supabase project + Pages preview branch, so migrations and releases rehearse before production. 10. CI on the GitHub org: typecheck + tests on every PR (GitHub Actions), EAS robot token for builds. 11. Store release pipeline: EAS Build → TestFlight/Play internal → staged rollout; crash-gated promotion.
Compliance & support (with the lawyer) 12. DPIA + registro de tratamientos; DPAs with Supabase/Cloudflare/Expo on file; retention jobs implemented; delete-account tested end-to-end. 13. Support operations: contact@ ownership + response target, in-app feedback triage ritual, public status page.
The doc-02 target. Do not migrate on a date — migrate on a trigger:
Triggers (any of): sustained p95 latency degradation on core RPCs · Supabase plan ceilings (connections/compute) at ~70% · cost crossover where AWS is materially cheaper at our load · an enterprise/partner requirement (e.g. dedicated infra for employer deals).
Intermediate step first: Supabase Pro → Team/dedicated compute usually buys 10–100× headroom without any migration. Evaluate before AWS.
If triggered — migration plan (eu-west/eu-south region, GDPR): 14. AWS landing zone: Organizations account under company root, IAM Identity Center with the 3+1 model, billing alerts, EU region only. 15. Database: RDS/Aurora PostgreSQL inside a private VPC — private subnets only, no public endpoint, security groups allowing just the API layer, KMS encryption at rest, credentials in Secrets Manager with rotation; replicate schema + RLS policies + RPCs (they are plain SQL — portable by design); migrate auth (Supabase GoTrue export → Cognito or self-hosted GoTrue). 16. Data cutover: logical replication → freeze window → switch connection strings (config.ts is the single point) → verify → keep Supabase as rollback for 30 days. 17. Edge/API layer: PostgREST or a thin API service (ECS/Fargate) replacing Supabase's auto-API; Cloudflare stays as CDN/DNS/Access — no change to the surfaces. 18. Re-run the FULL launch-readiness checklist (B1) against the new stack + load tests before cutover.
El stack Supabase + Cloudflare sirve de sobra la fase inicial de crecimiento; estas tareas lo hacen de grado producción. Todas son trabajo pre-lanzamiento:
Pagos y negocio 1. Procesamiento de pagos para el modelo 4,99€ + employer: Stripe (web) y/o RevenueCat (suscripciones in-app iOS/Android/web) — tabla de entitlements en Supabase, webhooks, periodos de gracia, facturas. 2. Puertas de precio/entitlement en la app (mapa free vs pago).
Observabilidad y alertas 3. Monitorización de errores: Sentry en app + web (residencia de datos UE), etiquetado por release para que cada OTA mapee a sus errores. 4. Monitorización de uptime de los 3 hostnames públicos + salud de Supabase; alertas a un canal de founders. 5. Retención de logs de Supabase; dashboards básicos (altas, usuarias activas, tasa de error) más allá de los KPIs actuales.
Endurecimiento de seguridad 6. Rate limiting + protección anti-bots: reglas WAF de Cloudflare y Turnstile en registro y waitlist; cuotas por usuaria en los RPCs de escritura. 7. Rotación de secretos + auditoría de dependencias (npm audit + Dependabot en los repos de la organización). 8. Simulacro de restauración de backup — restaurar de verdad un snapshot en un proyecto de prueba y verificarlo (un backup nunca restaurado es una hipótesis); activar PITR (Supabase Pro). 8b. Base de datos en zona segura: activar las restricciones de red de Supabase (la base de datos accesible solo desde IPs permitidas — el acceso SQL directo nunca abierto a internet), SSL obligatorio en toda conexión, cifrado en reposo verificado, y auditoría del par de claves anon/service (la service_role solo en el gestor). Los clientes hablan SOLO a través de la API protegida por RLS — nunca directamente con la base de datos.
Ingeniería de releases 9. Entorno de staging: segundo proyecto Supabase + rama preview de Pages, para ensayar migraciones y releases antes de producción. 10. CI en la organización de GitHub: typecheck + tests en cada PR (GitHub Actions), token robot de EAS para builds. 11. Pipeline de tiendas: EAS Build → TestFlight/Play interno → rollout escalonado; promoción condicionada a crashes.
Cumplimiento y soporte (con el abogado) 12. DPIA + registro de tratamientos; DPAs con Supabase/Cloudflare/Expo archivados; trabajos de retención implementados; borrado de cuenta probado de extremo a extremo. 13. Operativa de soporte: responsable y objetivo de respuesta de contact@, ritual de triaje del feedback in-app, página de estado pública.
El objetivo del doc 02. No se migra por fecha — se migra por trigger:
Triggers (cualquiera): degradación sostenida de latencia p95 en los RPCs core · techos del plan de Supabase (conexiones/cómputo) al ~70% · cruce de costes donde AWS sea materialmente más barato a nuestra carga · requisito enterprise/partner (p. ej. infraestructura dedicada para acuerdos employer).
Paso intermedio primero: Supabase Pro → Team/cómputo dedicado suele dar 10–100× de margen sin migrar nada. Evaluarlo antes que AWS.
Si se dispara — plan de migración (región eu-west/eu-south, RGPD): 14. Landing zone de AWS: cuenta de Organizations bajo raíz de empresa, IAM Identity Center con el modelo 3+1, alertas de facturación, solo región UE. 15. Base de datos: RDS/Aurora PostgreSQL dentro de una VPC privada — solo subredes privadas, sin endpoint público, security groups que permiten únicamente la capa API, cifrado en reposo con KMS, credenciales en Secrets Manager con rotación; replicar esquema + políticas RLS + RPCs (son SQL puro — portables por diseño); migrar auth (export de GoTrue → Cognito o GoTrue auto-alojado). 16. Corte de datos: replicación lógica → ventana de congelación → cambio de connection strings (config.ts es el punto único) → verificación → mantener Supabase como rollback 30 días. 17. Capa edge/API: PostgREST o un servicio API ligero (ECS/Fargate) sustituyendo la auto-API de Supabase; Cloudflare sigue como CDN/DNS/Access — las superficies no cambian. 18. Re-ejecutar la checklist COMPLETA de B1 sobre el stack nuevo + pruebas de carga antes del corte.
┌──────────────────────────────────────────────────┐
users ─────────► │ CLOUDFLARE (edge — unchanged) │
(4 surfaces: │ DNS · CDN · WAF · DDoS · Zero Trust Access │
web, PWA, └───────────────────────┬──────────────────────────┘
iOS, Android) │ HTTPS only
┌───────────────────────▼──────────────────────────┐
│ AWS eu-central-2 (Zurich) │
│ ┌────────────────────────────────────────────┐ │
│ │ PUBLIC SUBNET │ │
│ │ ALB (TLS termination, health checks) │ │
│ └───────────────────┬────────────────────────┘ │
│ ┌───────────────────▼────────────────────────┐ │
│ │ PRIVATE SUBNETS (VPC) │ │
│ │ ECS Fargate services: │ │
│ │ · API layer (PostgREST / thin API) │ │
│ │ · Auth (GoTrue / Cognito adapter) │ │
│ │ · Workers (retention jobs, exports) │ │
│ │ │ │ │
│ │ Aurora PostgreSQL (Multi-AZ, KMS at rest, │ │
│ │ RLS + RPCs ported 1:1, no public endpoint)│ │
│ └────────────────────────────────────────────┘ │
│ S3 (assets, JSON exports, backups·lifecycle) │
│ Secrets Manager (rotated creds — no keys in │
│ code) · CloudWatch + OpenTelemetry (p95, │
│ error rate, alerts) · AWS Backup (cross-AZ) │
└──────────────────────────────────────────────────┘
EN — What changes and what doesn't: the four surfaces, Cloudflare edge, deploy commands and the RLS security model do not change — clients keep calling the same API shapes; config.ts is the single switch point. What changes underneath: the database moves into a private VPC (Aurora Multi-AZ, KMS, reachable only from the API services), auth runs as our own service, background jobs get a proper worker, secrets rotate in Secrets Manager, and observability becomes first-class (CloudWatch/OTel with alerting). Region eu-central-2 (Zurich) per the doc-02 residency target — EU/Swiss health-data guarantees preserved.
ES — Qué cambia y qué no: las cuatro superficies, el edge de Cloudflare, los comandos de despliegue y el modelo de seguridad RLS no cambian — los clientes siguen llamando a la misma API; config.ts es el único punto de conmutación. Lo que cambia por debajo: la base de datos pasa a una VPC privada (Aurora Multi-AZ, KMS, accesible solo desde los servicios API), la autenticación corre como servicio propio, los trabajos de fondo tienen worker de verdad, los secretos rotan en Secrets Manager, y la observabilidad pasa a primera clase (CloudWatch/OTel con alertas). Región eu-central-2 (Zúrich) según el objetivo de residencia del doc 02 — garantías UE/Suiza para datos de salud preservadas.