Producto con IA
De la idea a algo que la gente puede abrir y usar hoy
Vengo del marketing, no de la ingeniería, y eso define cómo construyo: empiezo por a quién le sirve y cómo se va a medir, no por la arquitectura. Lumi salió de una idea a una app desplegada, con chat de IA en tiempo real, detección de crisis y un journey gamificado, construida en React 19 sobre Supabase con Claude. La construí yo, de punta a punta. Eso es lo que ofrezco: llevar una idea a algo que se pueda usar, no a un documento de sesenta páginas.
- Para quién
- Fundadores y equipos de marketing con una idea de producto que quieren validarla con algo funcionando, no con una presentación.
- Qué resuelve
- Ideas que se quedan en documentos y en prototipos de Figma porque nadie las lleva a producción, y cotizaciones de desarrollo que no caben en el presupuesto de una validación.
- Qué te llevas
- Un producto acotado, desplegado y con analítica desde el primer día, con el código y las cuentas a tu nombre.
En resumen
- La diferencia entre una idea y un producto es que el producto se abre en el navegador. Lo demás es un documento.
- Lumi es la prueba: app de bienestar emocional con chat de IA en tiempo real, detección de crisis y journey gamificado, en React 19, Supabase y Claude.
- Trabajo por recorte: definimos la única cosa que la versión uno tiene que hacer bien y todo lo demás se anota para después.
- La IA rinde en conversación guiada y clasificación. En "un agente que hace todo solo" casi siempre es humo: sin procesos definidos, automatizas el desorden.
- El código, el repositorio y las cuentas quedan a tu nombre desde el primer commit.
Cómo llevo una idea a producción
El error más común no es técnico: es querer lanzar con todo. Un producto que hace ocho cosas a medias no se puede evaluar, porque cuando no funciona no sabes cuál de las ocho falló. Por eso la primera conversación siempre es de recorte.
Las cinco etapas
- Recorte: definimos la única cosa que la versión uno debe hacer bien. El resto se anota en una lista y se deja para después, no se discute otra vez.
- Flujo y pantallas: diseño las pantallas reales, no wireframes grises, porque el diseño resuelve la mitad de las decisiones de producto antes de escribir código.
- Datos y cuentas: modelo de datos, autenticación y permisos resueltos antes de meter una sola llamada al modelo.
- Capa de IA: dónde el modelo aporta de verdad, con instrucciones acotadas y un plan explícito para cuando se equivoque.
- Deploy y medición: sale a producción con analítica desde el día uno, porque un producto sin datos de uso no se puede mejorar.
El stack con el que trabajo
Uso pocas herramientas y las conozco bien. En un MVP la variedad del stack no es virtud: cada pieza extra es algo más que mantener cuando la idea todavía no está validada.
- React para la interfaz, porque es donde puedo iterar más rápido sobre el diseño.
- Supabase como base de datos, autenticación y tiempo real, sin montar servidores propios.
- Claude para la capa de IA, con las instrucciones y los límites definidos por escrito.
- Vercel para desplegar, con cada cambio publicable en minutos.
- Git y GitHub desde el primer día, con el repositorio a tu nombre.
Qué no soy
No soy una fábrica de software ni armo equipos de diez personas. No tomo proyectos de seis meses con especificación cerrada, porque en ese formato lo que se entrega ya no es lo que el negocio necesita.
Trabajo en ciclos cortos con una persona decidiendo del otro lado. Si tu proyecto necesita cumplimiento normativo pesado, integraciones bancarias o un equipo de mantenimiento permanente, te conviene una casa de software y te lo digo antes de cotizar.
Lumi: el ejemplo que puedes abrir
Lumi es un producto propio, no un encargo, y por eso puedo mostrarlo completo. Es una app de bienestar emocional donde la conversación con IA ocurre en tiempo real, con detección de señales de crisis y un journey gamificado para sostener el hábito, que es el problema real de esta categoría.
Lo importante para este servicio no es la app en sí, sino que existe: está desplegada, se abre en el navegador y se puede usar. Un portafolio de producto donde todo son mockups no prueba que sepas terminar algo.
Qué hay dentro
- Chat con IA en tiempo real, no un formulario que responde en diferido.
- Detección de señales de crisis, con una ruta distinta cuando la conversación lo requiere.
- Journey gamificado, porque en bienestar el reto no es la primera sesión sino la décima.
- React 19 en el front y Supabase como base de datos, autenticación y capa de tiempo real.
- Desplegada y accesible en la web: no es un prototipo clickeable en Figma.
Qué aprendí construyéndola
Tres cosas que ahora aplico en cualquier proyecto. La primera: el costo del modelo se diseña, no se descubre en la factura; el largo del contexto y cada cuánto llamas al modelo son decisiones de producto.
La segunda: la latencia percibida importa más que la real, y una respuesta que empieza a aparecer de inmediato se siente mejor que una perfecta que llega tres segundos después. La tercera: cuando el tema es sensible, hay que definir de antemano qué hace el sistema cuando no debe responder, y eso se prueba explícitamente.
Dónde la IA aporta y dónde es humo
La IA no es una función que se agrega al final para poder decir que el producto la tiene. O resuelve un problema concreto del usuario, o es peso muerto que además cuesta plata por cada uso.
| Uso | Veredicto | Condición para que funcione |
|---|---|---|
| Conversación guiada con el usuario | Sí, es donde más rinde | Instrucciones acotadas y salida clara hacia un humano |
| Clasificar y etiquetar lo que entra | Sí, barato y confiable | Categorías definidas por el negocio, no improvisadas |
| Redactar contenido en volumen | Con cuidado | Alguien que edite: publicar sin revisar sale caro en SEO |
| Recomendar productos | Depende del catálogo | Datos propios suficientes; con catálogo chico gana una regla simple |
| Un agente que hace todo solo | Casi siempre humo | Procesos ya definidos; si no, automatizas el desorden |
Qué pasa después del deploy
Lanzar es el principio. Las primeras dos semanas son las que enseñan de verdad: dónde se atasca la gente, qué función nadie usa y qué pregunta repiten todos. Por eso el producto sale con analítica desde el primer día, con los eventos clave del recorrido definidos antes de publicar.
A partir de ahí decidimos con datos qué entra en la siguiente versión y qué se elimina. Eliminar funciones también es trabajo de producto, y suele ser el que más mejora la experiencia. Si prefieres seguir tú solo desde ese punto, no hay problema: el repositorio y las cuentas ya son tuyas y quedan documentadas.
Preguntas frecuentes
¿Cuánto cuesta construir un MVP con IA?
Depende del alcance que definamos en el recorte, y esa conversación es gratis. Un producto con una funcionalidad central bien hecha cuesta una fracción de lo que cuesta uno con ocho pantallas y tres integraciones. Cotizo por proyecto con alcance cerrado por escrito, y aparte quedan los costos de infraestructura y de la API del modelo, que se pagan por consumo y van a tu nombre.
¿Cuánto se demora en estar en producción?
Con el alcance bien recortado, semanas y no meses. Lo que estira los tiempos casi nunca es programar: es no tener decidido a quién le sirve el producto ni qué hace exactamente en la versión uno. Por eso invierto la primera parte del proyecto en cerrar eso. Si a mitad de camino cambia el alcance, se recotiza; no lo meto por debajo de la mesa.
¿De quién queda el código y las cuentas?
Tuyas, desde el primer commit. El repositorio se crea a tu nombre y las cuentas de infraestructura y de la API se abren con tu correo y tu método de pago. Trabajo con acceso, no con propiedad, igual que en las cuentas publicitarias. Si mañana quieres seguir con otro desarrollador, no tienes que pedirme nada ni esperar a que yo entregue algo.
¿Qué necesito de mi lado para empezar?
Claridad sobre el problema que resuelve el producto y para quién, más una persona disponible para decidir rápido durante el proyecto. No necesitas requerimientos escritos ni conocimiento técnico: eso lo armamos juntos en la fase de recorte. Lo que sí necesitas es aguantar que te diga que no a funciones, porque ahí es donde se salva el proyecto.
¿Y si la idea no funciona?
Es un resultado válido y es exactamente para lo que sirve un MVP: descubrirlo en semanas y con poca plata, en vez de en un año. Por eso el producto sale con medición desde el día uno, con criterios de éxito acordados antes de lanzar. Si los datos dicen que no, lo digo. Prefiero eso a venderte una segunda fase sobre algo que ya mostró que no tiene demanda.
¿Esto reemplaza a un equipo de desarrollo?
No, y no pretende hacerlo. Reemplaza al documento de requerimientos y al prototipo en Figma que nadie puede usar. Sirve para validar rápido, mostrar algo real a un socio o a un cliente y llegar con evidencia a la conversación de inversión. Cuando el producto demuestra tracción y necesita escalar, ahí sí toca un equipo, y en ese momento el código documentado que dejo es el punto de partida.
Sigue por acá
Caso Lumi
El producto completo: qué decisiones tomé, qué recorté y cómo llegó a producción.
Ver página→trabajoCaso Asignar
Campañas y funnels de performance, que es la otra cara del mismo trabajo: producto que además tiene que vender.
Ver página→serviciosE-commerce
Si lo que quieres vender ya existe, muchas veces conviene una tienda bien armada antes que un producto nuevo.
Ver página→serviciosSEO y SEM
Un producto que nadie encuentra no se valida: hay que resolver también de dónde llega la gente.
Ver página→Actualizado el