HPC
Cuatro productos para el Hospital Privado de Comunidad de Mar del Plata, en web y en el teléfono, con un mismo design system.
El hospital tenía el diseño de cuatro productos: una app para pacientes, el consultorio, la recepción y un panel de dirección. Eran 60 pantallas entre web de escritorio y teléfono. Además, la paleta del diseño no cumplía WCAG 2.1 AA, y la propuesta lo prometía.
Tres decisiones que lo definieron.
- 01
Un paquete de tokens para web y nativo
Por qué. Color, tipografía, espaciado e íconos viven en TypeScript, en @hpc/tokens. Las primitivas web y las de React Native leen de ahí. La app de pacientes se ve igual que las de escritorio sin copiar valores.
El costo. Se comparten tokens y lógica, no componentes. Hay dos librerías de primitivas que mantener a la par: CSS Modules en web y React Native en el teléfono.
- 02
El contrato de la API se genera, no se escribe
Por qué. La API en Go publica OpenAPI 3.1 desde sus propios tipos. Un paquete lo convierte en los tipos de TypeScript que importa el cliente de la API. Un satisfies rompe el build si el backend agrega un valor que nadie mapeó.
El costo. Hay un paso de generación, y el backend manda sobre la forma de los datos. Una prueba dorada detecta un contrato viejo, pero sólo cuando corre.
- 03
El tiempo real avisa qué cambió, no cómo quedó
Por qué. Cada app abre un solo WebSocket y se suscribe a temas como una agenda o una sala de espera. Un aviso sólo invalida el caché, y la pantalla vuelve a pedir por el camino de siempre. Un turno sacado en la app aparece solo en recepción.
El costo. Cada aviso cuesta un pedido extra. Las ráfagas dispararían varios renders del servidor en Next.js, así que el canal puede agrupar avisos.
HPC
Cuatro productos para el Hospital Privado de Comunidad de Mar del Plata, en web y en el teléfono, con un mismo design system.
- Rol
- Arquitectura y desarrollo completo
- Stack
- Next.js 16, Expo / React Native, TypeScript, TanStack Query, Turborepo, Go
- En vivo
- hpc-demo.vercel.app ↗
El hospital tenía el diseño de cuatro productos: una app para pacientes, el consultorio, la recepción y un panel de dirección. Eran 60 pantallas entre web de escritorio y teléfono. Además, la paleta del diseño no cumplía WCAG 2.1 AA, y la propuesta lo prometía.
Tres decisiones que lo definieron.
Un paquete de tokens para web y nativo
Por qué. Color, tipografía, espaciado e íconos viven en TypeScript, en @hpc/tokens. Las primitivas web y las de React Native leen de ahí. La app de pacientes se ve igual que las de escritorio sin copiar valores.
El costo. Se comparten tokens y lógica, no componentes. Hay dos librerías de primitivas que mantener a la par: CSS Modules en web y React Native en el teléfono.
El contrato de la API se genera, no se escribe
Por qué. La API en Go publica OpenAPI 3.1 desde sus propios tipos. Un paquete lo convierte en los tipos de TypeScript que importa el cliente de la API. Un satisfies rompe el build si el backend agrega un valor que nadie mapeó.
El costo. Hay un paso de generación, y el backend manda sobre la forma de los datos. Una prueba dorada detecta un contrato viejo, pero sólo cuando corre.
El tiempo real avisa qué cambió, no cómo quedó
Por qué. Cada app abre un solo WebSocket y se suscribe a temas como una agenda o una sala de espera. Un aviso sólo invalida el caché, y la pantalla vuelve a pedir por el camino de siempre. Un turno sacado en la app aparece solo en recepción.
El costo. Cada aviso cuesta un pedido extra. Las ráfagas dispararían varios renders del servidor en Next.js, así que el canal puede agrupar avisos.