Gabriel Herencia

~/insights / Cloud & DevOps

Construyendo Wallida: un SaaS multi-tenant para salud mental

Las decisiones de ingeniería detrás del MVP de Wallida: aislamiento multi-tenant con Row Level Security de PostgreSQL, dos modos en un mismo producto y datos listos para IA.

·2 min de lectura
Cloud & DevOpsSeguridadWallidaSaaSMulti-tenantPostgreSQL

De cuadernos y Excel a una sola plataforma

Wallida nació de un problema concreto: los profesionales de salud mental gestionan su práctica con herramientas dispersas —Excel, WhatsApp, cuadernos, carpetas físicas— y terminan dedicando más tiempo a administrar que a atender. La apuesta fue construir el sistema operativo de la práctica de salud mental: una sola plataforma para pacientes, sesiones, notas clínicas, cobranza y formularios, que sirve tanto a un psicólogo independiente como a una clínica o un colegio.

Este es un vistazo a las decisiones de ingeniería detrás del MVP. Documento vivo: lo voy detallando a medida que el producto evoluciona.

El reto central: multi-tenant de verdad

Cada clínica, consultorio o colegio es un tenant con su espacio aislado. La regla número uno: los datos de una organización jamás deben filtrarse a otra. En salud mental, donde el dato es sensible, esto no es negociable.

La decisión clave fue empujar el aislamiento hasta la base de datos, no dejarlo solo en el código de la app. Cada tabla con datos de tenant tiene Row Level Security (RLS) de PostgreSQL: aunque una query se equivoque, el motor solo devuelve las filas de la organización del usuario autenticado.

renderizando diagrama…

La seguridad es en capas: JWT para identidad, validación estricta de entrada, protección anti-escalada de privilegios, rate limiting y, debajo de todo, RLS como última línea que no depende de que el código sea perfecto.

Dos modos en un mismo producto

Un tenant puede activar el modo clínico, el educativo, o ambos:

  • Clínico: pacientes, sesiones, notas (SOAP / DAP / evaluación), objetivos terapéuticos, cobranza y paquetes de sesiones.
  • Educativo: alumnos, entrevistas, formularios oficiales (UGEL) con generación de PDF, y portal de docentes.

El registro self-serve detecta el tipo de práctica y adapta la plataforma a lo que cada quien usa. Es el mismo código sirviendo a cuatro perfiles distintos (independiente, clínica, centro, colegio) sin forks.

Lo que ya está construido

El backend está maduro: API multi-tenant, 18 módulos, ~115 endpoints, 425 tests automatizados y un pipeline de auditoría en cada cambio. Funciona de punta a punta: cobranza (un ledger con saldos, vencimientos y paquetes por cuotas controlados con triggers de la base), dashboard de señales, portales de padres y docentes, gestión de equipo, suscripciones con trial de 30 días y un panel de super-admin para operar todos los tenants.

Datos para el futuro

La analítica está instrumentada (GA4 → BigQuery) desde el día uno: no solo para medir conversión, sino para tener datos estructurados que, más adelante, alimenten features de IA (resúmenes entre sesiones, alertas en notas, sugerencias de seguimiento).

Stack, en una línea

Frontend React 19 + Vite + TypeScript + Tailwind; backend Fastify + Supabase (PostgreSQL con RLS); analítica GA4 → BigQuery. Arquitectura vertical slice (modular, fácil de mantener), con repos separados para front, back y base.

Lo que más me importa como ingeniero: el aislamiento multi-tenant a nivel de base, la misma disciplina de select-only-seguridad-en-produccion aplicada al diseño, y dejar los datos listos para la siguiente etapa.