Cuaderno del fundador
Un proyecto improbable
Septiembre de 2026
Empecé a construir Health Mirror en febrero de 2026.
Como una semana después, ya lo tenía funcionando de principio a fin en mi teléfono.
Recuerdo haber pensado: Vaya. Esto funciona de verdad.
En realidad, no funcionaba. :)
Pero esa primera semana me demostró algo que probablemente era más importante.
La distancia entre tener una idea y construirla se había vuelto de pronto mucho más corta.
Era product manager principal.
Normalmente, mi trabajo consistía en definir el qué y el porqué. Traducir eso en el cómo implicaba trabajar con un equipo completo de I+D, IT, operaciones y muchos más.
Los modelos de lenguaje (LLM) cambiaron esa relación para mí. De pronto tenía un compañero de IA guiándome por un territorio desconocido, aunque no fuera precisamente en línea recta. :)
Health Mirror se convirtió en mi experimento para ver hasta dónde podía llegar eso.
Y entonces mi app de una semana chocó con la realidad.
La primera versión mantenía todo en el teléfono, incluida la inferencia de IA.
Me encantaba esa arquitectura. Capturar la imagen localmente, prepararla localmente, ejecutar el modelo localmente, guardar el resultado localmente.
Luego intenté convertirla en una app real para iOS y Android.
Durante un mes, jugué al cazatopos tecnológico intentando alinear las cadenas de dependencias de las funciones críticas.
Solucionaba una incompatibilidad y aparecía otra. Actualizaba una dependencia y otra cosa dejaba de funcionar.
Tras un mes de jugar al cazatopos, mi compañero de IA dijo finalmente: «No tengo más sugerencias. Este es un ecosistema que evoluciona muy rápido. Tal vez sea posible a finales de año».
Nos dimos por vencidos.
Mis notas del proyecto se volvieron bastante categóricas:
## ⚠️ Known Constraints & Decisions
### ❌ Abandoned Approach
* TensorFlow.js + React Native (Expo)
* Reason: incompatible with modern RN/Expo architecture
Y también:
## 🧠 Key Lessons Learned
* On-device AI with Expo + TFJS is not viable (current ecosystem)
* Native/runtime layer matters more than JS layer for ML
...
Así que cambié el equipo.
Traje a un segundo compañero de IA.
Entre los tres ya éramos suficientes para rebotar ideas. Con el tiempo, uno se convirtió en mi arquitecto y el otro en mi programador.
Por esa misma época, descubrí algo un poco vergonzoso sobre mi modelo. :)
La primera versión usaba softmax, que gestiona una elección exclusiva en el reconocimiento de imágenes. Luego pasé a lo que creía que era sigmoid, que permite múltiples etiquetas independientes por imagen, algo mucho más adecuado para las observaciones de los patrones de la lengua.
En realidad era un sigmoid simulado, no el auténtico.
Así que volvimos a entrenar el modelo.
Y lo entrenamos de nuevo para optimizar la calidad de los resultados.
Y otra vez más. :)
Para abril, ya no estábamos parcheando el enfoque anterior.
Lanzamos un giro completo.
¿Qué es lo mínimo que realmente necesita salir del teléfono?
Esa pregunta desbloqueó la arquitectura.
En lugar de forzar la captura de la cámara, la decodificación de la imagen, la preparación del tensor y la inferencia de machine learning a través de una misma cadena de dependencias compatibles tanto para iOS como para Android, trasladamos una sola función muy específica a la nube:
La inferencia.
Todo lo demás podía quedarse en el propio dispositivo, donde yo quería que estuviera.
La versión más temprana de ese diseño todavía contemplaba enviar la imagen al servicio de inferencia. Mis notas de aquel momento eran así:
## 🔐 Privacy Design (MVP)
* Images sent to server for inference
* No persistent storage of images
* Processing done in-memory
* HTTPS required for production
## 🧭 Future Considerations (Post-MVP)
...
* Possible future migration: ONNX Runtime (on-device AI)
Más adelante, logramos experimentar con separar también la preparación del tensor sin causar un impacto destructivo en la delicada cadena de dependencias, de modo que ya no hacía falta enviar la imagen original a la nube para la inferencia.
Solo se envía el tensor numérico.
El servicio ejecuta el modelo y devuelve una lista de puntuaciones de confianza en la predicción.
El teléfono construye todo lo demás.
La respuesta técnica cambió bastante.
El principio, no.
Quería que la seguridad y la privacidad estuvieran ahí desde la primera línea.
Tengo una verdadera pasión por la seguridad, la privacidad y el cumplimiento normativo.
Me parecen divertidos.
Sí, por lo visto hay gente para todo. :)
Incluso me preparé y aprobé el examen CISSP (Certified Information Systems Security Professional), que abarca ocho dominios de conocimientos en ciberseguridad y suele asociarse mucho más a profesionales dedicados a la seguridad y las TI que a los product managers.
Siento cierta responsabilidad de hacer que la seguridad esté presente cuando tengo la oportunidad.
Sin embargo, tras años en el mundo corporativo, había un patrón que no dejaba de frustrarme:
Construir el sistema. Conectarlo todo. Recopilar los datos.
La privacidad y la seguridad suelen quedar para después.
Para entonces, muchas de las decisiones importantes ya se han tomado. Los cambios son caros, a veces incluso económicamente prohibitivos.
Con Health Mirror, tuve la oportunidad de invertir esa secuencia haciéndome una pregunta muy simple desde el principio:
¿Realmente necesitamos que estos datos salgan del dispositivo?
Antes del lanzamiento, también hicimos nuestra propia revisión de privacidad y seguridad, no porque nadie nos lo exigiera, sino porque quería que la implementación, la política de privacidad y lo que le decimos a la gente coincidieran entre sí.
Tras meses construyendo de esta manera, teníamos buenas razones para creer que así era, pero una comprobación final aún podía detectar algo que se hubiera pasado por alto.
Mi «app de una semana» llevó otros seis meses.
Hubo muchísimas otras aventuras entre aquel primer prototipo y el lanzamiento.
Pero esto es probablemente lo que más me sorprendió:
La IA no me dio mágicamente todas las respuestas. Me permitió llegar al siguiente problema mucho, mucho, mucho más rápido.
Aprendí el machine learning suficiente para descubrir por qué mi primer modelo estaba equivocado.
La ingeniería móvil suficiente para descubrir por qué mi primera app no era realmente una app.
La arquitectura suficiente para saber cuándo debía cambiar un diseño que me encantaba.
Y cuando nos topábamos con algo que no entendíamos, los tres podíamos investigarlo, cuestionar nuestras suposiciones, aprender algo nuevo y volver a intentarlo.
Seis meses después de mi app «funcional» de una semana —mientras seguía trabajando a tiempo completo—, Health Mirror se convirtió en algo que otras personas podían descargar de verdad.
Mi softmax se convirtió en sigmoid.
Mi único compañero de IA se convirtió en dos.
Mi arquitectura totalmente local sumó un servicio en la nube deliberadamente minúsculo.
Y mi experimento se convirtió en un producto.
Es un camino bastante diferente del que imaginaba en febrero.
Me alegro de no haber sabido todo lo que venía. :)