Cómo un product manager sin background técnico armó dos pilotos en una semana con Claude y Kiro

Un product manager sin experiencia práctica en desarrollo describió un caso en el que en una semana construyó y desplegó dos pilotos funcionales con la ayuda de Claude, Kiro, Figma Make y servidores MCP. La historia es interesante no solo por el resultado en sí, sino también por cómo cambia la barrera de entrada para lanzar primeras versiones de un producto sin un equipo de ingeniería completo.

De qué se compone el stack

En la base del flujo está la división de roles entre varias herramientas de IA. El autor utilizó Claude Sonnet 4.5 para descubrimiento: se cargaban audiencia, puntos de dolor, jobs-to-be-done, limitaciones y valor de negocio. El resultado incluía analítica, contenido y prompts para las siguientes etapas. Figma Make era responsable de la generación del frontend, y Kiro de Amazon se encargaba del ensamblaje, decisiones arquitectónicas y deploy. Como infraestructura se utilizó Supabase para la base de datos, GitHub Pages para hosting y servidores MCP para contexto y pruebas.

• Claude Sonnet 4.5 — descubrimiento, analítica, contenido y prompt del sistema
• Figma Make — generación del frontend para la versión piloto
• Kiro — ensamblaje del proyecto, documentación de soluciones y deploy
• Supabase y GitHub Pages — base de datos y publicación
• Context7 y Playwright vía MCP — memoria entre sesiones y verificaciones e2e básicas

Este conjunto es interesante porque no intenta forzar una herramienta a hacer todo a la vez. El autor distribuyó tareas según los puntos fuertes de cada servicio y así redujo la cantidad de ediciones manuales. Según su evaluación, solo en la etapa de analítica y diseño se logró ahorrar alrededor de 40 horas — precisamente porque los artefactos del descubrimiento pasaban a la generación de la interfaz y luego al ensamblaje con pérdidas mínimas.

Flujo paso a paso

El proceso comenzaba no con código, sino con la definición del problema. Para cada producto se creaba un asistente separado en Claude, al que se le pasaba todo el contexto: quién es el usuario, qué problema resuelve el servicio, qué cuenta como valor y qué limitaciones no se pueden violar. Después, los materiales se transferían a Figma Make, donde se generaba un frontend sin refinamiento manual. En el caso, se trataba de dos proyectos: un sitio personal de consultoría en productos y una herramienta ágil gratuita que el autor considera como una alternativa temprana a Jira para startups.

El siguiente paso era pasar el frontend y la analítica a Kiro. El autor destaca esta herramienta como el centro de todo el pipeline, porque Kiro primero formula las soluciones por escrito y luego las implementa, sin saltar directamente al código. Después se conectaban tres servidores MCP: Context7 para mantener el contexto entre sesiones, Supabase MCP para esquema de base de datos y migraciones, Playwright MCP para verificar escenarios críticos del usuario.

La etapa final se veía maximamente práctica: registro en GitHub y Supabase, creación de base de datos, deploy en GitHub Pages e instrucciones para vincular dominio.

Dónde están los cuellos de botella

El autor formula directamente la limitación principal: este flujo funciona bien para pilotos y MVPs, pero no resuelve cuestiones de calidad en el camino hacia producción completa. Si el producto está diseñado para alta carga, integraciones complejas o soporte a largo plazo, la arquitectura aún necesita ser revisada por una persona. Esto especialmente aplica a las decisiones que Kiro puede tomar automáticamente: el artículo señala que algunas se ven cuestionables sin una revisión técnica básica.

Lo mismo aplica a las ventanas de contexto: Context7 ayuda a no perder el hilo del proyecto, pero no hace que el problema de memoria desaparezca completamente.

"Vibe-coding no es un reemplazo para desarrolladores."

Otro riesgo está relacionado con las pruebas. Playwright MCP, según la observación del autor, cubre con seguridad el happy path, es decir escenarios básicos, pero no elimina la necesidad de verificar por separado edge cases. Por lo tanto, el stack descrito se ve como una herramienta para verificación rápida de una hipótesis y un proceso predecible para un product manager no técnico; su debilidad es la necesidad de traer un ingeniero a tiempo cuando el piloto comienza a convertirse en un producto real.

Qué significa esto

El caso demuestra un cambio en la economía del lanzamiento: hoy un product manager o founder puede construir un piloto funcional sin contratar un equipo y semanas de preparación, si puede formular claramente requisitos y montar herramientas en un flujo consistente. Pero ese también es el límite del enfoque: la IA acelera el primer lanzamiento, no la disciplina de ingeniería, cuando un producto comienza a crecer.