White-label por subdominio
Cada organización vive en su propio subdominio con su nombre, color y logo, y tiene su página pública indexable por buscadores.
Caso · Plataforma SaaSEn desarrollo
Nutreitor
Plataforma SaaS multi-tenant y white-label para nutrición deportiva: nutricionistas, deportistas, clubes y gimnasios.
- NestJS
- Next.js
- PostgreSQL
- AWS
El desafío
Qué había que resolver
Nutreitor es una plataforma para nutricionistas deportivos, sus deportistas, clubes y gimnasios: captación de pacientes, ficha clínica, planes alimentarios con cálculo nutricional, agenda, seguimiento y reportes, en un mismo producto.
El desafío: un único despliegue tenía que servir a muchas organizaciones, cada una con su marca y su subdominio, y lo que se guarda son datos de salud. El aislamiento entre organizaciones no podía depender de que el código "no se equivoque".
La solución
Qué construimos
Tres experiencias en un producto
Un panel para el profesional, un portal instalable (PWA) para el deportista y una administración para el consultorio, cada una con sus permisos.
Cálculo nutricional integrado
Planes alimentarios vinculados a una base de alimentos, con macros calculados, objetivos por tipo de día (entrenamiento, partido, descanso) y lista de compras.
Asistentes de IA
Agentes de IA para el profesional y el deportista, con contexto clínico minimizado y supervisión, sobre Amazon Bedrock.
Notificaciones en segundo plano
Un worker que envía recordatorios de turnos, avisos de mensajes y reportes por email, sin incluir datos clínicos.
Arquitectura
Cómo se arma en AWS
La plataforma está en desarrollo: esta es la arquitectura en AWS que diseñamos y que guía su puesta en producción.
| Pieza | Servicio de AWS | Por qué |
|---|---|---|
| Web, API, agentes y worker | Amazon ECS FargateContenedores stateless que escalan por separado, en subnets privadas. | Contenedores stateless que escalan por separado, en subnets privadas. |
| Entrada y subdominios | ALB + Route 53 + ACMUn certificado wildcard para un subdominio por organización; la API no queda expuesta. | Un certificado wildcard para un subdominio por organización; la API no queda expuesta. |
| Landing | Amazon S3 + CloudFrontSitio estático rápido y barato, separado del producto. | Sitio estático rápido y barato, separado del producto. |
| Base de datos | Amazon RDS PostgreSQLMulti-AZ, cifrada con KMS, con Row Level Security por organización. | Multi-AZ, cifrada con KMS, con Row Level Security por organización. |
| Colas y rate limiting | Amazon ElastiCache (Redis)Contadores de uso y cola del worker de notificaciones. | Contadores de uso y cola del worker de notificaciones. |
| Amazon SESAvisos transaccionales dentro de la misma cuenta y permisos. | Avisos transaccionales dentro de la misma cuenta y permisos. | |
| IA | Amazon BedrockLos datos de salud no salen del perímetro de AWS. | Los datos de salud no salen del perímetro de AWS. |
| Secretos | AWS Secrets ManagerCredenciales inyectadas en tiempo de ejecución, nunca en el código. | Credenciales inyectadas en tiempo de ejecución, nunca en el código. |
Decisiones clave
Lo que hace la diferencia
- 01
El aislamiento lo garantiza la base de datos
Row Level Security forzada en PostgreSQL: sin organización fijada no se ve ninguna fila. Un test automático falla si aparece una tabla sin protección.
- 02
Roles de base de datos con lo justo
La API, los agentes y el worker usan roles distintos, ninguno con privilegios para saltear el aislamiento.
- 03
Monolito modular a propósito
Una API stateless que escala horizontalmente; se extrae un servicio solo cuando hay un motivo real, como pasó con los agentes de IA y el worker.
- 04
Decisiones documentadas
Cada decisión con trade-offs tiene su registro de arquitectura (ADR), para que el equipo entienda el porqué de cada pieza.
Servicios
Lo que aplicamos en este proyecto
Otros casos: Gennos (movilidad y transporte) · Banndo (infraestructura cloud)