Un sistema donde lo que un paciente registra cada día llega a su nutricionista.
Nuvra conecta el registro diario de comidas con el seguimiento profesional: una app mobile para el paciente, un panel web para el nutricionista y la misma información circulando entre los dos.
Visitar Nuvra ↗
La nutrición no pasa en la consulta
La consulta ocurre cada varias semanas. La alimentación ocurre todos los días.
Nuvra nace de cruzar dos cosas que hoy funcionan por separado: el registro diario de lo que alguien come y el seguimiento que un nutricionista hace en consultas espaciadas.
El paciente genera información todos los días. El profesional trabaja con encuentros puntuales. Entre una consulta y la siguiente, esa información queda en el teléfono del paciente o depende de lo que pueda reconstruir de memoria cuando vuelve.
La oportunidad no era construir otra app de calorías. Era conectar los dos tiempos: que lo que se registra a diario llegue como información útil a quien acompaña el proceso.
En el medio quedan las comidas, las decisiones y las dudas de todos los días: el material con el que después se trabaja en la consulta.
Dos aplicaciones, un solo sistema
Nuvra no es una app con un panel de administración al lado. Son dos experiencias diferentes, pensadas para dos trabajos distintos, sobre la misma información.
Definir esa relación fue la primera decisión de arquitectura: qué produce cada lado, qué necesita ver el otro y en qué momento la información cruza. El paciente registra y consulta su día. El profesional lee, interpreta y devuelve. Ninguno de los dos usa la herramienta del otro.
- 01Paciente
Registra una comida desde el teléfono.
- 02Sistema
El registro queda disponible dentro del seguimiento.
- 03Nutricionista
Ve el día de esa persona en su panel.
- 04Nutricionista
Deja una observación sobre lo registrado.
- 05Sistema
La observación queda asociada a esa comida.
- 06Paciente
La lee en su día, sin salir de la app.
Lo importante es que la relación entre paciente y profesional existe explícitamente dentro del sistema: sin ese vínculo no hay a quién mostrarle un registro, y con él todo lo que el paciente carga tiene destinatario.
Registrar una comida no debería ser una tarea
El registro manual es la parte más costosa de cualquier app de alimentación: buscar el alimento, elegir la variante correcta, calcular la cantidad, cargar los macronutrientes. Todos los días, varias veces por día.
Decidí resolver ese momento con una foto: la IA estima calorías y macronutrientes, y esos valores llegan cargados en el formulario.
La IA acá no es una función para mostrar: reduce el costo de una tarea que hay que repetir todos los días, y de esa repetición depende que exista información para el seguimiento.
La estimación llega editable. El registro sigue siendo del usuario.
Una estimación a partir de una foto no puede presentarse como un dato exacto: si el sistema se equivoca y la persona no puede intervenir, el registro deja de ser confiable para las dos personas que dependen de él.
La información no termina en el teléfono
Del lado del nutricionista el problema deja de ser registrar y pasa a ser leer. Alguien con varios pacientes activos no necesita ver todo lo que cada uno cargó.
Por eso el panel trabaja en dos niveles, y cada uno existe para responder una pregunta distinta. No son dos pantallas del mismo tamaño de problema.
¿Quién necesita mi atención hoy?
El panel general no muestra comidas: muestra estados. Pendiente de revisión, fuera de objetivo, bajo registro o sin actividad ordenan la lista antes de que el profesional abra nada. La decisión de información acá fue mostrar menos por paciente para poder mostrarlos a todos.
¿Qué está pasando con esta persona?
El detalle individual sí entra en el día: calorías y macronutrientes contra el objetivo, la evolución de las últimas dos semanas, los objetivos cargados y la próxima sesión. Es la vista donde el profesional se prepara para hablar con alguien.
Diseñar seguimiento, no juicio
La primera versión resolvía la devolución con dos acciones: el nutricionista podía aprobar o rechazar cada comida registrada. Sobre el papel cerraba: el profesional revisa, el paciente recibe una respuesta.
Varios nutricionistas probaron el MVP y ese fue el punto que más comentarios trajo. Un veredicto binario sobre lo que alguien comió no se parece a cómo trabajan: una consulta no aprueba ni rechaza platos, revisa un período y devuelve una observación. Y del lado del paciente, un rechazo en el teléfono es difícil de leer como acompañamiento.
Cambié la interacción. Hoy el eje del panel es revisar: los estados hablan de comidas sin revisar, y lo que llega al paciente es un mensaje de su nutricionista dentro del registro.
Aprobar / Rechazar
Revisar / Observar
No fue un cambio de copy: cambió qué se espera del profesional y qué recibe el paciente por haberlo registrado.
Ahí se cierra el recorrido. Lo que alguien registró un martes vuelve como una observación de su nutricionista, sin esperar a la próxima consulta.
El MVP está construido y funciona.
Además de definir el producto y diseñar las dos experiencias, construí Nuvra hasta un MVP funcional mediante desarrollo asistido por IA con Claude Code.
Pensar el concepto, definir la arquitectura entre paciente y profesional, diseñar la interfaz y construirla fueron partes del mismo trabajo. Cada decisión se pudo probar sobre un producto que corre, no sobre una pantalla.
Eso también es lo que hizo posible iterar cuando los nutricionistas devolvieron sus comentarios: el cambio se pudo hacer en el producto, no en un archivo de diseño.
- Vinculación con un nutricionista por código
- Registro de comidas con foto
- Estimación de calorías y macronutrientes con IA, editable antes de guardar
- Día, objetivos y comidas registradas
- Observaciones del nutricionista sobre cada registro
- Panel con el estado de todos los pacientes
- Estados de revisión y de objetivo
- Detalle individual por paciente
- Calorías, macronutrientes y evolución
- Objetivos y próxima sesión
- Observaciones sobre los registros
Probado por profesionales, todavía no por pacientes
Varios nutricionistas usaron el MVP y me devolvieron comentarios. Ese feedback fue la fuente real de las iteraciones del producto, incluida la más importante: la que cambió la lógica de aprobación por una de revisión.
No fue un estudio de research ni un test con usuarios finales, y no quiero presentarlo como si lo fuera: fueron profesionales usando un producto funcional y diciéndome qué no cerraba con su forma de trabajar.
Nuvra todavía no fue probado con pacientes reales. Esa es la parte que falta, y es la que decide si el sistema sirve.
Lo verificado hasta acá
- El MVP funciona de punta a punta, en mobile y en web.
- Nutricionistas reales lo usaron y devolvieron comentarios.
- Ese feedback produjo cambios concretos en el producto.
Lo que falta validar
- Qué pasa cuando alguien registra todos los días durante semanas.
- Si el seguimiento entre consultas cambia algo en una relación profesional sostenida.
- Qué parte del sistema genera suficiente valor como para sostener un negocio.
Diseñar un sistema es decidir qué ve cada uno.
Nuvra me obligó a pensar más allá de una interfaz: dos usuarios distintos, dos dispositivos y una sola información que tenía que significar cosas diferentes de cada lado.
Lo que más me enseñó no fue la IA ni el panel, sino haber diseñado una interacción razonable que igual estaba mal, y haberla cambiado porque las personas que iban a usarla me explicaron por qué.