Saltar al contenido principal
Proyectos Live

Root PWA

El usuario fotografía un producto y en segundos sabe si puede comerlo con sus restricciones activas (celiaquía, diabetes, intolerancia a la lactosa), combinables entre sí. Root va más allá del scanner: recetas curadas con filtrado estricto y diario alimentario offline para quien ya sabe qué no puede comer y quiere saber qué sí.

Por Valentina Ramírez · Actualizado: 19 de junio de 2026

Ver sitio en vivo

Resumen

PWA offline-first que escanea etiquetas de alimentos con IA (Claude API) y dice al instante si puedes comer un producto según tus restricciones (celíaco, diabético, intolerante a la lactosa). Django, DRF, PostgreSQL, React.

Stack
DjangoDRFPostgreSQLReactTypeScriptClaude APIPWA
01

El problema

Comer con celiaquía, diabetes o intolerancia a la lactosa implica leer cada etiqueta, descifrar ingredientes escondidos bajo otros nombres y buscar recetas que cumplan varias restricciones a la vez, todo de forma manual y dispersa.

02

Qué construí

  1. 01

    PWA offline-first con Service Workers: el diario de consumo funciona sin conexión y sincroniza al recuperarla.

  2. 02

    Scanner de etiquetas por IA: el usuario fotografía un producto y Claude API analiza los ingredientes contra su perfil de restricciones activo.

  3. 03

    Perfil de salud persistente que condiciona todas las respuestas del modelo (celiaquía, diabetes tipo 2, intolerancia a la lactosa, combinables).

  4. 04

    Sistema de recetas curadas con filtrado estricto por múltiples condiciones simultáneas.

  5. 05

    Backend en Django REST Framework + PostgreSQL; frontend en React + TypeScript.

Scanner de etiquetas

Fotografía un producto y la IA analiza los ingredientes contra el perfil activo del usuario, incluyendo ingredientes ocultos bajo nombres técnicos.

Recetas curadas

Catálogo filtrado por restricciones múltiples: una receta se valida contra celiaquía, diabetes e intolerancia a la lactosa al mismo tiempo.

Diario alimentario

Registro de consumo con soporte offline completo. Los registros se persisten localmente y sincronizan al recuperar la red.

03

Decisiones de arquitectura

1. Nicho médico real, no wellness genérico

Contexto
Existen muchas apps de comer sano. Las personas con celiaquía, diabetes o intolerancia tienen necesidades concretas y consecuencias reales si se equivocan.
Trade-off
Un producto más amplio alcanza más usuarios pero diluye la propuesta y baja el estándar de validación.
Decisión
Root está diseñada para quien tiene una condición médica diagnosticada. Eso define el catálogo, los criterios del scanner y cómo se presentan los resultados.

2. Restricciones compuestas: lógica AND, no OR

Contexto
Un usuario puede tener celiaquía, diabetes e intolerancia a la lactosa al mismo tiempo. La mayoría de apps aplican restricciones en silo.
Trade-off
Validar una restricción es simple. Validar tres simultáneamente con ingredientes ocultos bajo nombres técnicos exige un modelo de perfil persistente y prompts específicos.
Decisión
El perfil de salud es estado persistente, no contexto de sesión. Cada análisis del scanner valida contra todas las restricciones activas al mismo tiempo.

3. PWA offline-first para el diario alimentario

Contexto
El registro de consumo ocurre en el momento, no siempre con buena señal.
Trade-off
Una app web tradicional falla sin conexión. Una app nativa requiere publicación en stores y más mantenimiento.
Decisión
Service Worker que persiste el diario localmente y sincroniza en batch al recuperar la red. Se instala desde el navegador sin pasar por App Store.
04

Resultados

  • Scanner de etiquetas funcional: el usuario fotografía un producto y Claude API analiza los ingredientes contra su perfil de restricciones activo, incluso cuando varias condiciones aplican a la vez.

  • Diario de consumo operativo sin conexión gracias al diseño offline-first; los registros se persisten en local y sincronizan al recuperar la red.

  • Núcleo completo en producción: perfil de salud persistente, scanner por IA y recetas con filtrado estricto sobre Django REST Framework, PostgreSQL y React.

05

Aprendizajes

  • Offline-first no es una capa que se añade al final: condiciona el modelo de sincronización desde el primer endpoint y obliga a resolver conflictos de datos en vez de asumir una única fuente de verdad.

  • Para que las respuestas del modelo sean fiables, el perfil de salud no puede ir solo en el prompt: tratar las restricciones como estado persistente y verificable, y no como contexto que se pierde entre peticiones, es lo que evita falsos seguros al combinar celiaquía, diabetes e intolerancia a la lactosa.

A un click

Tu próxima idea merece
código que la sostenga.

Diseño y construyo productos completos: del backend a la interfaz que tus usuarios aman. Con IA integrada y seguridad desde el diseño.

Proyectos desde COP 2.000.000 / USD 500 según alcance (MVP desde 3-6 semanas).

Disponibilidad limitada, respondo en 24h.

Quiero mi producto Ver servicios