Caso de Estudio: Construyendo Zalud, una plataforma de historia clínica del paciente

Zalud se propuso algo que suena simple y no lo es: darle a las personas la propiedad real de su historia clínica. La promesa, “Tu historia clínica, con vos”, implica que datos de salud sensibles tienen que ser portables, privados y correctos. Eso no deja espacio para los atajos que están bien en un MVP desechable y que en un producto de salud se vuelven, en silencio, pasivos.

Fluxa Labs construyó la plataforma desde cero — arquitectura, backend, el panel de administración y la puesta en producción — de punta a punta, con un solo ingeniero senior, del primer commit a producción en menos de ocho semanas.

Qué construimos

El producto tiene dos caras:

• Una app para el paciente, donde las personas acceden y son dueñas de su historia clínica.
• Un panel de administración, construido con React + Vite, para gestionar pacientes, registros clínicos y los documentos asociados, con acceso por roles para el equipo que opera la plataforma.

La arquitectura, y por qué

Para un equipo pequeño construyendo un producto de salud, la decisión correcta fue un stack ligero y centrado en la seguridad, con la menor cantidad posible de infraestructura indiferenciada que cuidar.

• Supabase como columna vertebral: Postgres gestionado, autenticación, almacenamiento de archivos y, sobre todo, row-level security (RLS). RLS te deja aplicar el aislamiento de datos dentro de la propia base de datos. Un paciente solo puede leer sus propios registros, sin importar lo que haga la capa de aplicación. Para datos de salud, llevar el control de acceso a la capa de datos es la diferencia entre “esperamos que la API esté bien” y “la base de datos lo garantiza”.
• Vercel para el hosting y el despliegue: preview deploys en cada cambio, una red edge global y cero servidores que mantener. El foco se queda en el producto, no en la operación.
• React + Vite para el panel de administración: un build rápido y un ciclo de feedback ágil para las herramientas internas de las que depende la operación diaria.

La disciplina que importa acá no son los logos del stack. Son las decisiones detrás de ellos: modelar los datos para que la privacidad sea estructural, no algo agregado después, mantener pocas piezas móviles y apoyarse en servicios gestionados para que un equipo pequeño entregue funcionalidades en lugar de mantener infraestructura.

El resultado

Entregado en menos de ocho semanas, por un solo ingeniero:

• 18 migraciones de base de datos versionadas — cada cambio de esquema revisable y reproducible
• 44 políticas de row-level security — el aislamiento de los datos del paciente garantizado dentro de la base de datos, no solo en la API
• 9 edge functions serverless para la lógica de backend
• Un panel de administración completo en React + Vite con acceso por roles

Para comparar: el presupuesto típico de una agencia para un build así es un equipo de 3–4 personas durante uno o dos trimestres. Zalud llegó al mercado en una fracción de ese tiempo y costo — sin sacrificar el nivel de seguridad que exige un producto de salud.

Zalud se lanzó como una plataforma centrada en la privacidad, donde los pacientes son realmente dueños de sus registros, sobre una base que un equipo pequeño puede operar y extender con confianza, no una que necesite un sprint de rescate doce meses después.

Escúchalo de la CEO de Zalud, Natalia Blanco:

La conclusión

No necesitas un equipo grande para construir un producto serio. Necesitas la arquitectura correcta, decidida temprano, por alguien que ya llevó sistemas a producción, para que las decisiones caras de deshacer se tomen bien la primera vez.

Esa es toda la idea detrás de Fluxa Labs. Si estás construyendo algo donde el estándar técnico importa, conversemos.