Lumi
De la idea al deploy: cómo construí Lumi con React, Supabase y Claude
Llevo más de seis años trabajando marketing y diseño, y durante buena parte de ese tiempo opiné sobre producto sin haber construido uno. Lumi nació justamente de esa incomodidad: quería saber si podía cerrar el ciclo completo, de la idea al deploy, sin delegar la parte que no dominaba. Elegí un tema difícil a propósito, bienestar emocional, porque obliga a tomar decisiones de criterio y no solo de interfaz. Lo que sigue es el recorrido real del proyecto: qué decidí construir, qué dejé por fuera y qué aprendí en el camino.
- Cliente
- Producto propio
- Año
- 2026
- Rol
- Idea, diseño de producto, desarrollo y deploy. Todo el proyecto, de punta a punta.
- Resultado
- De la idea al deploy, con el MVP en vivo
- Para quién
- Fundadores y equipos de marketing que tienen una idea de producto con IA y no saben si se puede llevar a algo real y publicado.
- Qué resuelve
- La distancia entre un prototipo bonito en Figma y una aplicación desplegada, con base de datos, sesión de usuario y un modelo respondiendo de verdad.
- Qué te llevas
- Ver cómo se recorta el alcance de un MVP con IA, qué stack lo sostiene y qué decisiones hay que tomar antes de escribir la primera línea.
En resumen
- Lumi es producto propio: no hubo cliente, ni brief, ni presupuesto de pauta. Fue el proyecto donde comprobé que puedo llevar una idea de IA hasta un deploy público.
- Está armado con React 19 en el front, Supabase como base de datos y sesión, y Claude como motor de conversación.
- Tiene tres piezas: chat en tiempo real, detección de crisis y un journey gamificado que le da continuidad al uso.
- La decisión más difícil no fue técnica sino de criterio: qué hace la app cuando aparece una señal de riesgo. La respuesta fue sacar la conversación del chat, no resolverla dentro.
- El MVP está publicado y cualquiera puede abrirlo. No es un prototipo clickeable: es una aplicación desplegada.
El punto de partida: una idea que no se podía quedar en Figma
Vengo de diseñar y de vender, no de programar. Eso significa que durante años entregué conceptos de producto que alguien más tenía que traducir a código, y en esa traducción se perdían justo las decisiones que importaban: qué pasa cuando falla, qué se guarda, qué se muestra primero.
Lumi empezó como la prueba de que ese hueco se podía cerrar. No había cliente que pagara, así que tampoco había excusa: si el proyecto no llegaba a producción, no había a quién echarle la culpa.
Las tres reglas que me puse antes de empezar
- Tenía que quedar publicado en una URL que cualquiera pudiera abrir, no en un demo local.
- Tenía que resolver una conversación real con un modelo, no simular respuestas escritas de antemano.
- Si aparecía un tema sensible, la app tenía que tener una respuesta pensada de antemano, no improvisada por el modelo.
Qué decidí hacer: un MVP con el alcance recortado a propósito
La tentación en un producto con IA es meter todo lo que el modelo puede hacer. Ahí es donde mueren los MVP: en la lista de funcionalidades que nadie pidió. Recorté el alcance a lo mínimo que hacía la aplicación defendible, y dejé el resto anotado para después.
El orden en el que tomé las decisiones
- Primero el criterio: qué debe hacer la app frente a una señal de riesgo. Eso condiciona todo lo demás, incluso el tono de la interfaz.
- Después la conversación: cómo se siente hablar con Lumi y qué tan rápido responde, porque una conversación lenta no se siente como conversación.
- Luego la continuidad: sin una razón para volver, un chat de bienestar se usa una vez. De ahí salió el journey gamificado.
- Al final la infraestructura: base de datos, sesión y deploy. Es la parte que más se nombra y la que menos define si el producto sirve.
Lo que entró en el MVP
- Chat con IA en tiempo real, con la respuesta apareciendo mientras se genera en lugar de un bloque que llega al final.
- Detección de crisis: señales que cambian el flujo de la conversación en vez de dejarla correr.
- Journey gamificado que le da progresión al uso y una razón concreta para volver al día siguiente.
- Sesión persistente, para que la conversación siga siendo la misma cuando el usuario vuelve.
Lo que dejé fuera, y por qué
Nada de esto se descartó por difícil. Se descartó porque no cambiaba la respuesta a la única pregunta que tenía el MVP: ¿esto se siente útil la primera vez que lo abro?
- Cuentas con perfil completo y edición: agregan fricción antes de que la persona vea el valor.
- Panel de métricas para el usuario: es la funcionalidad que suena bien en la demo y nadie abre dos veces.
- App nativa: en un MVP, la web hace el mismo trabajo y se publica el mismo día.
- Integraciones con calendario o recordatorios externos: dependen de que el hábito ya exista.
Cómo se ejecutó: el stack, capa por capa
El stack se eligió por una razón simple: quería la menor cantidad de piezas posible entre la idea y algo publicado. Cada herramienta que se suma es una que hay que mantener, así que la pregunta en cada capa fue cuál es lo mínimo que resuelve esto bien.
| Capa | Herramienta | Por qué esa |
|---|---|---|
| Interfaz | React 19 | Componentes y estado sin traer un framework completo encima para un MVP de una sola vista principal. |
| Conversación | Claude | El producto trata temas sensibles: pesaba más el manejo del tono que la velocidad bruta. |
| Datos y sesión | Supabase | Base de datos y autenticación en una sola pieza, sin montar un backend propio para el MVP. |
| Publicación | Vercel | Deploy continuo desde el repositorio: cada cambio queda en línea sin ritual de despliegue. |
La conversación en tiempo real
Una respuesta que aparece completa después de varios segundos se siente como un formulario. Una que se va escribiendo se siente como una conversación. Es la misma latencia, pero la percepción cambia por completo, y en un producto de acompañamiento esa percepción es el producto.
La decisión más delicada: la detección de crisis
Este fue el punto donde tuve que decidir qué tipo de producto estaba construyendo. Un chat de bienestar puede intentar sostener cualquier conversación, o puede reconocer cuándo la conversación lo excede. Elegí lo segundo: la detección de crisis existe para cambiar el flujo cuando aparecen señales de riesgo, no para que el modelo se haga cargo de algo que no le corresponde.
Lumi acompaña, no reemplaza atención profesional, y el producto tiene que decirlo con los hechos, no solo con un aviso legal en el pie.
Qué resultó: un MVP publicado, no un prototipo
El resultado del proyecto es verificable y por eso lo dejo con enlace: hay una URL pública, con la aplicación desplegada, funcionando con las tres piezas que definí al principio. No hay cifras de uso que mostrar y no voy a inventarlas: Lumi es un producto propio en fase de MVP, y el resultado que reclamo es exactamente ese, haber cerrado el ciclo completo.
Lo que quedó en pie
- Aplicación desplegada y accesible desde cualquier navegador.
- Conversación con IA respondiendo en tiempo real sobre datos y sesión reales.
- Criterio de manejo de señales de riesgo definido antes de escribir la funcionalidad, no después de un incidente.
- Un stack que puedo explicar, mantener y volver a usar en el próximo proyecto.
Qué me llevé
Lumi cambió la forma en que trabajo con clientes que quieren producto. Ya no discuto funcionalidades en abstracto: puedo decir cuánto pesa cada decisión porque la tomé y la sostuve.
- El criterio se define antes que la interfaz. Si no sabes qué hace el producto en su peor momento, la pantalla bonita no te va a salvar.
- En un producto con IA, el modelo es la parte fácil. Lo difícil es decidir qué NO debe hacer.
- Recortar alcance es una habilidad de negocio, no de ingeniería: cada funcionalidad que no entra es tiempo que sí llega al deploy.
- Construir el producto propio me dio el vocabulario para trabajar mejor con equipos técnicos en proyectos de cliente.
Preguntas frecuentes
¿Cuánto toma llevar un MVP con IA de la idea al deploy?
No te voy a dar el número de Lumi como si fuera un estándar, porque fue un producto propio que avanzó por rachas, entre proyectos de cliente. Lo que sí aplica a cualquier caso es el orden: cuando el alcance está recortado de verdad y las decisiones de criterio se toman antes de programar, el trabajo se mide en semanas, no en trimestres. Lo que estira los proyectos casi nunca es el código, es la indefinición.
¿Se puede hacer algo así para mi negocio sin un equipo técnico grande?
Sí, si el alcance es honesto. Herramientas como Supabase y los modelos por API quitaron del camino buena parte de lo que antes obligaba a montar un equipo. Lo que no se puede recortar es la definición del producto: qué resuelve, para quién y qué pasa cuando falla. Esa parte no la hace el stack.
¿Por qué Claude y no otro modelo?
Por el tipo de conversación que tiene Lumi. En un producto de bienestar emocional pesa más cómo maneja un tema delicado que qué tan rápido escribe. En otros proyectos la decisión puede ser distinta: si lo que necesitas es clasificar tickets o resumir texto, los criterios cambian y conviene comparar antes de casarse con uno.
¿Cuánto cuesta mantener una aplicación con IA?
El costo tiene dos partes: la infraestructura, que en un MVP es baja y bastante predecible, y el consumo del modelo, que sube con el uso. Por eso conviene estimar el costo por conversación desde el principio: es lo que te dice si el producto tiene modelo de negocio o solo tiene demo.
¿Lumi reemplaza terapia o atención profesional?
No, y el producto está diseñado para no pretenderlo. La detección de crisis existe precisamente para reconocer cuándo una conversación excede lo que una app puede acompañar. Es una decisión de producto, no un descargo de responsabilidad.
Sigue por acá
Producto digital con IA
El servicio detrás de este caso: cómo trabajo un producto con IA para un cliente.
Ver página→perfilSobre mí
De dónde sale el híbrido raro entre marketing, diseño y código.
Ver página→trabajoCaso Asignar
El otro proyecto que sigue en curso: campañas y funnels de performance.
Ver página→contactoContacto
Si tienes una idea de producto y quieres saber si se sostiene, hablemos.
Ver página→Actualizado el