App de bienestar para grupos pequeños: subes lo que comes, el grupo lo puntúa,
y la app cruza esas comidas con cómo te encuentras después.
Comer mal casi nunca es un problema de información: es un problema de inercia. Sabes lo que deberías comer y aun así abres la nevera y coges lo de siempre, porque nadie lo ve y no pasa nada.
Food Rank Challenge le pone testigos. Cada comida se fotografía y el resto del grupo la puntúa sobre unos criterios que el propio grupo define. Y como la app registra también cómo te encuentras —digestión, piel, energía, sueño—, con el tiempo deja de ser un juego y empieza a enseñar qué comidas te sientan mal.
No es una red social. Está pensada para grupos cerrados con relación real entre ellos: pareja, familia, compañeros de piso. Diseñarla para desconocidos destruiría lo único que la hace funcionar, que es que te importe quién puntúa.
| Feed del grupo | Evaluar una comida | Bienestar diario | Seguimiento de la piel |
![]() |
![]() |
![]() |
![]() |
Seis secciones: Inicio (el feed y lo que tienes pendiente de puntuar), Ranking (diario, semanal, mensual y global), Bienestar, Piel, Digestión y Mi perfil.
Lo que más se sale de lo previsto es el módulo digestivo: registro de deposiciones con
escala de Bristol, gases, síntomas, etiquetas de alimento propias, índices calculados y un
sistema de avisos (HealthWarning) que salta, por ejemplo, tras tres días sin deposición. Tiene
además sus propios ajustes de privacidad, porque no todo lo que se registra ahí se comparte con
el grupo.
flowchart TD
A["Subes la comida<br/>foto + tipo + comentario"] --> B["Queda pendiente<br/>para el resto del grupo"]
B --> C["Cada miembro la puntúa<br/>sobre los parámetros del grupo"]
C --> D["Media de la comida"]
D --> E["Ranking diario,<br/>semanal y global"]
A --> F["Evaluación automática<br/>con Gemini"]
G["Registro de bienestar,<br/>piel y digestión"] --> H["Cruce comida ↔ cómo te sienta"]
B -.->|"push"| I["Aviso: tienes<br/>comidas por puntuar"]
Tres reglas sostienen el diseño:
- No puedes puntuarte a ti mismo. Sin eso el ranking no vale nada.
- Lo pendiente se ve. Las comidas sin puntuar salen destacadas y generan aviso, porque un ranking a medio votar no dice nada.
- Los criterios los pone el grupo. Cantidad, valor nutricional, adecuación y presentación son solo los de partida: se pueden cambiar, reordenar y añadir los propios.
MVVM sobre Clean Architecture en tres capas, con Hilt inyectando las dependencias. El código recuperado enseña 9 repositorios, 38 modelos de dominio y 14 módulos de pantalla.
| Capa | Cómo está resuelto |
|---|---|
| UI | Jetpack Compose y Material 3, con Compose Navigation |
| Inyección | Hilt (Dagger) |
| Datos | Cloud Firestore, 15 colecciones (meals, evaluations, skin, bowelMovements, parameters…) |
| Sesión | Firebase Auth anónimo; el usuario entra por nombre contra la colección users y la sesión se guarda en SharedPreferences |
| Imágenes | Se comprimen a JPEG al 85 % en el dispositivo antes de subirlas |
| IA | Gemini 2.5 Flash evalúa la comida a partir de la foto |
| Avisos | Firebase Cloud Messaging, más recordatorios locales con AlarmManager que sobreviven al reinicio |
| Mínimo | Android 8.0 (API 26) |
El proyecto Android original se perdió. En referencia/ está el código de la
v19 recuperado con jadx a partir de la APK: no compila tal cual —es Java descompilado de
Kotlin— pero conserva íntegra la estructura y la lógica, y basta para reconstruir la app. El
LEEME explica qué se conserva, qué son los artefactos del compilador y
cómo regenerarlo.
Se conservan además los dos documentos con los que se diseñó, que siguen siendo la mejor puerta de entrada al proyecto:
| 🧭 Estrategia de producto | Para quién es, qué problema resuelve, qué entra en el MVP y qué se deja fuera |
| 🏗️ Arquitectura técnica | Stack, modelo de datos, reglas de seguridad, notificaciones y plan por sprints |
Antes de la app hubo un prototipo del flujo completo: un HTML autocontenido, sin dependencias ni
servidor, que guarda en localStorage. Se abre con doble clic
prototipo-web/index.html y se recorre el circuito entero.
Lo interesante no es solo lo que hace, sino dónde la realidad se apartó del plan:
| Decisión | Qué pasó |
|---|---|
| Grupos cerrados de 2 a 15 personas | Se mantuvo. Con desconocidos las puntuaciones dejan de importar |
| Sin conteo de calorías | Se mantuvo. Hay veinte apps que lo hacen mejor y ninguna consigue que las uses tres meses |
| Fotos comprimidas antes de subir | Se mantuvo, al 85 % de calidad. Una foto de 4 MB por comida agota cualquier plan gratuito en semanas |
| El registro de síntomas fuera del MVP | No se cumplió. El documento de producto recomendaba dejarlo fuera porque mezcla lo social con lo íntimo. Acabó siendo el módulo más desarrollado de la app, y con razón: es lo que convierte el juego en algo útil. La solución al conflicto no fue quitarlo, sino darle ajustes de privacidad propios |
| Gamificación aplazada a la fase 2 | Se cumplió. Medallas y rachas siguen sin estar; primero tenía que funcionar el circuito |
| Parámetros de evaluación fijos | Se quedó corto. Acabaron siendo configurables por el usuario, con orden y valores por defecto propios |
Es un proyecto en uso real, no un ejercicio, y tiene lo que tienen los proyectos en uso real:
- Había una clave de API en el código. La de Gemini estaba escrita como literal y, por tanto, embebida en la APK. Se retiró de la copia publicada y el 31-08-2026 se revocó y rotó: la clave que circula en las APK antiguas ya no funciona. La evaluación por IA queda fuera de servicio en la v19 hasta reconstruir la app sirviendo la clave desde un backend o Remote Config, nunca como literal.
- Las fotos van a un alojamiento público. Se suben a
catbox.moesin autenticación, así que quien tenga la URL ve la imagen. Para fotos de comida de un grupo cerrado, lo coherente es Firebase Storage con reglas por grupo. - Lo que se distribuye es un build
debug, sin minificar ni ofuscar. - La APK no se publica aquí, ni como release ni como artefacto: la app se conecta a una base de datos real con datos de personas.
MIT · Alejandro Valero Collante






