Módulo 3. Construir con IA

Lo que vas a lograr en este módulo

Al terminar esta semana vas a tener un producto mínimo publicado en internet, con una dirección que le podés mandar a cualquiera, tres personas reales que lo usaron y un registro escrito de lo que aprendiste mirándolas. No va a ser tu producto final. Va a ser la herramienta más barata que encontraste para aprender lo que todavía no sabés sobre tu problema.

Llegás con bastante trabajo hecho. En el módulo 1 elegiste un problema, lo escribiste como hipótesis y definiste criterios de corte. En el módulo 2 hablaste con personas que lo tienen y mediste interés con una página de prueba. Ahora toca construir. Y acá está la trampa: construir es la parte más divertida, la que más se parece a "hacer algo", y por eso es donde más fácil es perderse.

La inteligencia artificial cambió muchísimo esta etapa. Hoy podés describir una aplicación en español y tener una versión funcionando en una tarde. Eso también significa que podés construir en una tarde algo equivocado, inseguro o imposible de mantener. Este módulo te enseña a aprovechar la velocidad sin caer en esas trampas.

Vamos a recorrer diez temas:

1. Qué es un MVP de verdad (y qué no).
2. Los tipos de MVP, con casos reales.
3. Cómo elegir la única funcionalidad que importa.
4. El panorama de herramientas para construir con IA.
5. Qué es el "vibe coding" y dónde se termina.
6. Cómo escribir buenas instrucciones para construir.
7. Los riesgos: seguridad, datos, código que no entendés, dependencia y costos.
8. Publicar: dominio, hosting y analítica mínima.
9. Tus primeros tres usuarios y el registro de aprendizaje.
10. La IA como socia en esta etapa.

Todos los casos son reales y están documentados por sus protagonistas o por fuentes públicas. Las herramientas que nombramos existen a la fecha de escritura (septiembre de 2026), pero es un mercado que cambia cada mes. No damos precios, porque cambian todavía más rápido: revisalos siempre en la página de cada herramienta.

3.1 Qué es un MVP de verdad

MVP es la sigla en inglés de minimum viable product, producto mínimo viable. Es probablemente el término más usado y peor entendido del mundo emprendedor.

La definición que se usa hoy la popularizó Eric Ries en The Lean Startup (2011): el MVP es la versión de un producto nuevo que le permite a un equipo obtener la mayor cantidad de aprendizaje validado sobre sus clientes con el menor esfuerzo posible.

Fijate dónde está el acento. No dice "la versión más chica del producto". Dice aprendizaje. El MVP es, antes que nada, un experimento. Su trabajo es responder una pregunta que no podés responder de otra forma. El propio Ries insiste en que, a pesar del nombre, no se trata de hacer productos mínimos, y que si ya sabés con certeza cuál es el problema y cuál es la solución, no necesitás un MVP: necesitás construir.

El error más común: la versión chiquita del producto final

Casi todo el mundo, cuando escucha "MVP", piensa en esto: tomo mi producto ideal, con sus veinte funcionalidades, le saco quince y construyo las cinco que quedan. Eso no es un MVP. Es un producto incompleto.

La diferencia es de pregunta, no de tamaño. Una versión recortada responde "¿funciona lo que construí?". Un MVP responde "¿estaba en lo cierto sobre el problema, sobre el cliente o sobre lo que está dispuesto a hacer?". A veces esa respuesta se consigue sin escribir una línea de código.

Qué pregunta tiene que responder tu MVP

Volvé a tu hipótesis y a lo que aprendiste en el módulo 2. Probablemente ya sabés si el problema existe y le duele a alguien. Lo que no sabés todavía suele ser alguna de estas cosas:

• ¿Mi solución resuelve el problema, o lo cambia de lugar?
• ¿Lo van a usar de verdad? Decir "me interesa" en una entrevista es gratis. Volver a usar algo la semana siguiente, no.
• ¿Entienden cómo usarlo sin que se los expliques?
• ¿Cuál de las partes de la solución es la que importa? Muchas veces imaginás un producto de cinco partes y los usuarios usan una.

Elegí una: la que, si resulta falsa, te obliga a cambiar todo. Escribila en una oración. Esa es la pregunta de tu MVP. Si no podés escribirla, todavía no sabés qué construir.

3.2 Los tipos de MVP, con casos reales

Hay varias formas de responder la pregunta, y algunas son mucho más baratas que construir software. Estas son las cuatro más útiles para esta etapa.

El mago de Oz: parece automático, pero hay una persona atrás

En la película, el mago poderoso resulta ser un señor detrás de una cortina moviendo palancas. En este tipo de MVP, el cliente ve algo que parece automático, pero atrás hay una persona haciendo el trabajo a mano.

Caso real: Zappos. Ya lo viste en el módulo 1 como hipótesis; ahora miralo como MVP. En 1999, Nick Swinmurn quería saber si la gente compraría zapatos por internet sin probárselos. No armó un depósito. Sacó fotos de zapatos en negocios de su zona, las publicó en una web y, cuando alguien compraba, iba al negocio, compraba el par y lo enviaba. Para el cliente era una tienda online; atrás era Swinmurn caminando. Eric Ries usa este caso en The Lean Startup como ejemplo de experimento con clientes reales antes de invertir en infraestructura. Amazon compró Zappos en 2009, en una operación que al cierre se valuó en unos 1.200 millones de dólares.

Sirve cuando querés probar si la gente usa y paga por un resultado antes de automatizar cómo se produce. Es ideal para productos que prometen "hacer algo por vos": armar un presupuesto, recomendar algo, generar un informe. La advertencia: no engañes sobre lo que importa. Está bien que el cliente no sepa que un pedido lo procesa una persona. No está bien prometer lo que no vas a cumplir ni mentir sobre cómo usás sus datos.

El concierge: un servicio personal, a la vista

El concierge (conserje, como el de un hotel) es primo del mago de Oz, con una diferencia: el cliente sabe que lo atiende una persona. Le das el servicio a mano, uno por uno.

Caso real: Food on the Table. Manuel Rosso, que había sido el primer vicepresidente de marketing de IMVU (la empresa donde Eric Ries desarrolló buena parte de sus ideas), fundó en Austin, Texas, un servicio para planificar las comidas de la semana según lo que estaba en oferta en el supermercado de cada familia. En vez de programar el sistema, empezó con una sola clienta: una mamá que planificaba comidas y usaba cupones. Según el diario Austin American-Statesman, Rosso la acompañó durante semanas al supermercado, y cuando ella imprimió su primera lista se convirtió en la primera clienta y le pagó con un cheque. Ries cuenta en su libro que al principio la atendían en persona cada semana, armando a mano recetas y lista. Solo cuando el trabajo manual se volvió insostenible con más clientes empezaron a automatizar lo que más se repetía. En 2014 la empresa fue comprada por Scripps Networks Interactive.

El concierge te da algo que ningún software te da: estás sentado al lado del cliente mientras usa tu "producto". Ves dónde duda y qué ignora. Y aprendés qué conviene automatizar primero: lo que más veces hacés a mano.

La landing: una página que mide intención

La landing (página de aterrizaje) ya la conocés del módulo 2: describe el producto como si existiera y mide si la gente hace algo concreto.

Caso real: Buffer. En 2010, Joel Gascoigne quería construir una herramienta para programar publicaciones en Twitter. Venía, según contó, de perder un año y medio en proyectos que no había validado. Esta vez armó primero dos pantallas: una explicaba qué hacía Buffer y, al hacer clic en "planes y precios", la otra decía que todavía no estaba listo y pedía un email. Cuando vio que la gente se anotaba, agregó en el medio una pantalla con tres planes de precios, para medir si alguien elegía uno pago. Recién después construyó la primera versión, que lanzó el 30 de noviembre de 2010. Según Gascoigne, el primer cliente pago llegó a los cuatro días.

La landing responde bien preguntas de interés y de precio, y mal preguntas de uso: nadie usó nada todavía. Si ya tenés señales de tu landing del módulo 2, tu MVP de esta semana tiene que ir un paso más allá.

El MVP manual: pegado con cinta, pero funcionando

Es el que más vas a usar en este curso: un producto que resuelve el problema de punta a punta, armado con las piezas más simples que encontraste, muchas veces con partes hechas a mano. No es elegante ni escala. No importa.

Caso real: Groupon. A fines de 2008, Andrew Mason quería probar si la gente compraría cupones de descuento grupales en negocios de Chicago. Él mismo contó en una entrevista de 2010 con Mixergy cómo era la primera versión: un blog de WordPress con otro nombre, donde publicaban una oferta por día. Los cupones se generaban con una base de datos de escritorio (FileMaker) y un script que mandaba por mail un PDF a cada comprador. Cuando vendían 500 cupones de sushi en un día, mandaban 500 PDFs a la vez desde el programa de correo de una Mac. Lo describió como algo armado a los ponchazos, pero suficiente para probar que a la gente le gustaba.

Caso real: DoorDash. En enero de 2013, cuatro estudiantes de Stanford lanzaron PaloAltoDelivery.com: los menús de algunos restaurantes de Palo Alto en PDF y un número de teléfono. La gente llamaba, ellos tomaban el pedido (a veces en plena clase) y lo entregaban en sus propios autos. Ese mismo año se constituyeron como DoorDash.

Ninguno construyó el sistema que iba a necesitar si el negocio funcionaba. Construyeron lo mínimo para que funcionara esa semana, con clientes reales.

Cómo elegir el tipo

Los tipos se combinan: una pantalla hecha con IA donde el usuario carga sus datos, y vos procesando a mano lo que llega, está perfecto. La pregunta es siempre qué es lo más barato que podés hacer para aprender lo que necesitás.

Para este módulo, el resultado tiene que tener una URL pública. Eso casi siempre significa un MVP manual o un mago de Oz con alguna parte construida con IA. Si lo más inteligente en tu caso es un concierge, una página pública donde la persona pide el servicio también cuenta como producto publicado.

3.3 Elegir la única funcionalidad que importa

Cuando imaginás tu producto, probablemente imaginás registro de usuarios, un panel, configuración, notificaciones, historial. Todo eso tiene sentido para un producto maduro. Para un MVP, casi todo es ruido.

La regla de esta semana es dura: tu MVP tiene una sola funcionalidad central, la que resuelve el núcleo del problema que validaste.

Cómo encontrarla

1. ¿Cuál es el momento exacto en que duele? No un área entera ("[gestionar tal cosa]"), sino un momento concreto ("cuando [pasa tal cosa] y [la persona pierde tiempo, plata o clientes]"). Buscalo en tus notas de entrevistas del módulo 2.
2. ¿Qué tendría que pasar en ese momento para que deje de doler? Esa es la funcionalidad: "que [algo concreto ocurra] en ese momento".
3. ¿Qué es lo mínimo imprescindible para que eso pase? Probablemente no necesitás contraseñas ni panel. Quizás alcanza con un formulario, una lista y un mensaje.

Un buen truco: escribí el recorrido del usuario en cinco pasos o menos, desde que llega hasta que obtiene lo que vino a buscar. Si necesitás más, estás construyendo de más.

La lista de lo que no vas a construir

Tan importante como decidir qué hacer es escribir qué no vas a hacer. Candidatos típicos que casi nunca hacen falta en un MVP:

• Registro con contraseña (muchas veces alcanza con un email o un nombre), recuperación de contraseña, perfiles.
• Panel de administración (podés mirar los datos en una planilla o en la base de datos).
• Pagos automáticos (podés cobrar por transferencia o con un link de pago armado a mano).
• Notificaciones y recordatorios automáticos.
• Una app para celular aparte (una web que se vea bien en el teléfono alcanza).
• Varios idiomas, modo oscuro, integraciones.

Cada cosa que sacás es una cosa menos que puede fallar, que tenés que probar y mantener, y una puerta menos por donde se pueden filtrar datos. Gascoigne, el de Buffer, escribió después un artículo sobre todo lo que parecía imprescindible y con lo que igual lanzó sin ello, citando a Ries: el MVP probablemente tiene que ser mucho más mínimo de lo que pensás.

Antes de construir, contale a alguien tu MVP en dos oraciones: "Es para [quién]. Hace [una cosa] para que [resultado]". Si necesitás un "y además", recortá.

3.4 El panorama de herramientas

Hay tres grandes familias de herramientas. Conviene entender qué hace cada una antes de elegir.

Familia 1: constructores de aplicaciones con IA

Servicios web donde describís en lenguaje natural lo que querés ("una página donde [tus clientes] puedan [hacer algo] y yo vea [qué información]") y la herramienta genera una aplicación funcionando, que probás en el mismo navegador. Después seguís pidiendo cambios conversando. La mayoría también la publica con un par de clics y ofrece base de datos y usuarios.

• Lovable. Genera aplicaciones web completas a partir de una conversación. Se integra con Supabase para datos y usuarios, y permite sincronizar el código con GitHub, así queda también en tu poder.
• Bolt.new. De la empresa StackBlitz. Genera aplicaciones que corren en el navegador y soporta varias tecnologías, incluidas apps para celular.
• v0. De Vercel. Nació generando interfaces y hoy arma aplicaciones completas, con código pensado para que después lo siga un programador.
• Replit. Un entorno de programación en el navegador con un agente de IA que construye por vos, y que te deja ver y tocar todo el código.
• Base44. Un constructor con base de datos y usuarios incluidos. Es además un caso en sí mismo, que vas a ver en la sección 3.5.
• Google AI Studio. El entorno de Google para sus modelos Gemini incluye un modo para construir aplicaciones describiéndolas.

Son la mejor opción para la mayoría de las personas que no programan y quieren un MVP con pantallas y datos en una semana.

Familia 2: asistentes y agentes de programación

Trabajan sobre el código directamente, en tu computadora. Van desde editores con IA incorporada hasta agentes a los que les das una tarea y la ejecutan: leen archivos, escriben código, lo prueban y te muestran qué hicieron.

• Cursor. Un editor de código con IA integrada. Fue la herramienta que usaba Karpathy cuando nombró el vibe coding.
• Claude Code. El agente de programación de Anthropic, que trabaja desde la terminal o integrado en editores.
• Codex. El agente de programación de OpenAI.
• GitHub Copilot. El asistente de GitHub (Microsoft), integrado en los editores más usados.
• Windsurf. Otro editor con IA, hoy propiedad de la empresa Cognition.

Te dan más control y no te atan a una plataforma. A cambio, piden entender qué es un archivo, una terminal y un repositorio. Si nunca programaste, conviene empezar por la familia 1 y pasar a esta cuando el producto crezca.

Familia 3: herramientas sin código y piezas armables

Existían antes de la IA generativa y siguen siendo muy útiles. A veces combinar dos o tres es más rápido y más seguro que generar una aplicación desde cero.

• Sitios y landings: Carrd, Framer, Webflow.
• Formularios: Tally, Google Forms, Typeform.
• Datos: Airtable, Google Sheets.
• Aplicaciones a partir de una planilla: Glide, Softr.
• Aplicaciones más complejas sin código: Bubble.
• Automatizaciones (cuando pasa X, hacé Y): Zapier, Make, n8n.

Food on the Table o Groupon hoy probablemente se armarían así: un formulario, una planilla y una automatización que manda un mail. Nada que programar, nada que la IA pueda romper.

Cómo elegir

No te obsesiones con elegir la mejor. Elegí una, probala dos horas y, si no te sirve, cambiá. Para lo que tenés que construir esta semana, cualquiera de las principales alcanza.

3.5 Vibe coding: qué es y dónde se termina

El 2 de febrero de 2025, Andrej Karpathy publicó un mensaje en X que le puso nombre a algo que muchos estaban haciendo. Karpathy fue parte del equipo fundador de OpenAI y dirigió el área de inteligencia artificial de Tesla. Describió una forma nueva de programar a la que llamó vibe coding: dejarse llevar por la onda, aceptar todo lo que propone la IA y olvidarse de que el código existe.

Contaba que ya no leía los cambios que le proponía la herramienta: los aceptaba todos. Cuando aparecía un error, se lo pegaba a la IA sin comentario, y en general se arreglaba. Y cerraba con una advertencia que casi nadie citó: que no estaba tan mal "para proyectos descartables de fin de semana".

El término explotó. En noviembre de 2025, el diccionario Collins lo eligió como palabra del año.

Lo que el vibe coding sí permite

Caso real: fly.pieter.com. El 22 de febrero de 2025, Pieter Levels (el de los 12 productos en 12 meses del módulo 1) contó que nunca había hecho un videojuego y que acababa de construir un simulador de vuelo en el navegador pidiéndole todo a Cursor, en unas tres horas. Lo publicó en X, se volvió viral y empezó a vender publicidad dentro del juego. Según el propio Levels, llegó a un ritmo de facturación de un millón de dólares anuales en 17 días.

Ojo con leerlo mal. Levels llevaba más de diez años construyendo productos y tenía una audiencia enorme. La IA le resolvió la construcción; la distribución ya la tenía. Para vos, lo segundo va a ser lo difícil, y es el tema del módulo 5.

Caso real: Base44. Maor Shlomo, un programador israelí, arrancó Base44 solo, como proyecto paralelo: una herramienta para que personas sin conocimientos técnicos construyan aplicaciones describiéndolas. Según el medio israelí Calcalist, cuando lo vendió, en junio de 2025, tenía más de 100.000 usuarios, era rentable, nunca había levantado inversión y el equipo era de seis personas. Wix lo compró por 80 millones de dólares, con pagos adicionales atados a metas de ingresos.

Dónde se termina

Pocos meses después, el propio Karpathy mostró los límites. En abril de 2025 publicó un texto sobre MenuGen, una aplicación que construyó con vibe coding: le sacás una foto al menú de un restaurante y genera imágenes de cada plato. Su conclusión: hacerla andar en su computadora fue rápido y divertido; convertirla en una aplicación real, publicada, fue un trámite penoso.

Lo difícil no fue el código. Fue todo lo demás: configurar las claves de los servicios de IA, armar el inicio de sesión con Google, comprar y configurar un dominio, integrar pagos, pelearse con documentación desactualizada y con código que la IA escribía basándose en versiones viejas de esos servicios. Pasó más tiempo saltando entre paneles de configuración que dando instrucciones.

En junio de 2025, en la charla recomendada de esta semana, Karpathy volvió sobre esto con una idea para tatuarse: una demo funciona si anda en algún caso; un producto funciona si anda en todos. La IA acorta muchísimo el camino hasta la demo, y bastante menos el camino hasta el producto.

En la misma charla propone pensar la IA menos como un robot autónomo y más como el traje de Iron Man: algo que aumenta lo que podés hacer, pero que seguís manejando vos. Habla de un deslizador de autonomía (a veces le das mucha libertad, a veces poca, según lo que te juegues) y de mantener a la IA con correa corta: cambios chicos que puedas revisar rápido.

A principios de 2026, al cumplirse un año del mensaje original, Karpathy propuso otro nombre para lo que hacen los profesionales: agentic engineering, ingeniería con agentes. La diferencia es de actitud. El vibe coding es aceptar todo y ver qué sale. La ingeniería con agentes es dirigir, revisar y hacerse responsable de lo que los agentes producen.

Qué significa para vos

3.6 Cómo escribir buenas instrucciones para construir

Con estas herramientas, tu habilidad principal deja de ser programar y pasa a ser describir. Karpathy lo dijo en su charla de forma provocadora: de golpe todo el mundo es programador, porque todo el mundo habla un idioma. Es cierto a medias. Todo el mundo puede pedir. Pocos saben pedir bien. Estas cuatro prácticas son las que más ayudan.

1. Escribí una especificación de una página antes de abrir la herramienta

Una especificación es un documento corto que describe qué vas a construir. No tiene que ser técnico; tiene que ser claro:

Producto: [nombre provisorio] Para quién: [tu segmento, en una línea] Problema que resuelve: [el momento concreto en que duele] La única funcionalidad: [qué hace, en una oración] Recorrido del usuario: [de 3 a 5 pasos] Qué datos guarda: [lista de campos: nombre, email, fecha...] Qué NO hace (por ahora): [tu lista de la sección 3.3] Cómo se ve: [por ejemplo, "simple, colores claros, se usa sobre todo en el celular"] Pregunta que este MVP responde: [la de la sección 3.1]

Sirve tres veces: te obliga a pensar antes de construir, es lo primero que le pegás a la herramienta para que arranque con todo el contexto, y es tu vara para decir que no cuando a mitad de semana te tiente agregar algo.

2. Partí el trabajo en historias de usuario

Una historia de usuario describe una funcionalidad desde el punto de vista de quien la usa. Es una práctica de los equipos de desarrollo ágil desde hace más de veinte años, y funciona perfecto con una IA:

Como [tipo de usuario], quiero [hacer algo], para [lograr algo].

Abajo van los criterios de aceptación: las condiciones concretas para que la historia esté terminada. Completá esta plantilla con los datos de tu propio MVP:

Como [tipo de usuario de tu segmento], quiero [la acción de tu única funcionalidad], para [el resultado que le saca el dolor].

Criterios de aceptación: - Hay [pantalla o formulario] con [los campos que definiste en tu especificación]. - Al [acción del usuario], [qué ve o qué recibe como confirmación]. - [Quién recibe o administra los datos] ve [qué información], ordenada por [criterio]. - Si [falta un dato obligatorio o hay un error], [qué pasa y qué mensaje ve el usuario].

Tu MVP probablemente tenga entre tres y seis historias. Escribilas antes de empezar y ordenalas: primero la que resuelve el núcleo del problema.

3. Iterá de a poco

El error más común es pedir todo de una vez: "haceme una aplicación de [tu rubro] con [funcionalidad central], usuarios, notificaciones, panel y pagos". La herramienta va a generar algo que se ve bien y funciona a medias, con errores escondidos que no vas a saber dónde buscar.

Hacé lo contrario, que es lo que Karpathy llama correa corta:

• Pedile primero solo la estructura: "Leé esta especificación. Todavía no construyas nada: decime qué pantallas y datos vas a necesitar y qué dudas tenés".
• Una historia por mensaje. Si una es muy grande, partila.
• Cuando algo funciona, guardá ese punto. La mayoría de las herramientas tiene versiones o puntos de restauración; si trabajás con código, usá control de versiones (git). Si el próximo cambio rompe todo, volvés atrás en un clic en vez de pedirle a la IA que arregle lo que rompió.
• Si la IA da vueltas en círculos (arregla una cosa y rompe otra, tres veces seguidas), pará. Volvé al último punto que funcionaba y reformulá el pedido más chico.
• Cuando algo falla, dale contexto: el mensaje de error completo y qué estabas haciendo. "No anda" no le sirve a nadie.

4. Probá cada paso como si fueras el usuario

Después de cada cambio, usá el producto. No mires si "aparece la pantalla": hacé el recorrido completo. Cargá datos reales y datos raros (un nombre con tilde, un campo vacío, un número larguísimo). Abrilo en el celular. Probá los criterios de aceptación uno por uno.

La IA va a decirte con mucha seguridad que algo funciona. No le creas hasta verlo. En MenuGen, Karpathy cuenta que la IA le escribía código basado en versiones viejas de los servicios que usaba, y eso fallaba de maneras confusas. Probando cada paso, te enterás en el momento. Sin probar, te enterás cuando tu usuario te escribe que no anda.

3.7 Los riesgos

Construir rápido tiene costos que no se ven hasta que es tarde. No es para asustarte: es para que los tengas presentes desde el primer día, cuando evitarlos es fácil.

Seguridad

Una aplicación que se ve bien y funciona no es necesariamente segura. Y las herramientas de IA, si no se lo pedís, a veces generan aplicaciones con la puerta abierta.

Caso real: la vulnerabilidad de las apps de Lovable. El 20 de marzo de 2025, el investigador Matt Palmer detectó que muchas aplicaciones generadas con Lovable tenían mal configurada la protección de la base de datos que define qué filas puede ver cada usuario. Cualquier persona, sin iniciar sesión, podía leer o modificar datos de esas aplicaciones: nombres, emails, claves de otros servicios y datos de pagos. El análisis automático de los investigadores revisó 1.645 proyectos y encontró el problema en unos 170. Palmer avisó a la empresa al día siguiente, y la falla se hizo pública a fines de mayo de 2025 con el código CVE-2025-48757. Lovable incorporó un escáner de seguridad antes de publicar, aunque investigadores advirtieron que al principio solo verificaba que la protección estuviera activada, no que estuviera bien configurada.

No es un problema de una herramienta en particular. Es el problema de construir sin entender qué se construyó. Precauciones mínimas:

• Guardá solo los datos que necesitás. Lo que no guardás no se puede filtrar.
• Pedí una revisión de seguridad antes de publicar (hay un prompt en la sección 3.10) y usá el escáner de tu herramienta si lo tiene.
• Probá entrar como otro usuario. Creá dos cuentas y fijate si desde una ves los datos de la otra.
• Nunca pegues claves secretas (de pagos, de IA, de bases de datos) en el código visible de la página. Las herramientas serias tienen un lugar específico para guardarlas.
• No manejes datos sensibles (salud, finanzas, documentos) sin que alguien que sepa lo revise.

Datos personales

En Argentina, la Ley 25.326 de Protección de Datos Personales regula cómo se recolectan y usan los datos de las personas; la autoridad de control es la Agencia de Acceso a la Información Pública (AAIP). Lo vas a ver en detalle en el módulo 7. Por ahora: decile a la gente en lenguaje simple qué datos le pedís y para qué, no los uses para otra cosa, borralos si te lo piden y recolectá lo mínimo.

Código que no entendés

Cuando la IA construye algo que no entendés, perdés la capacidad de arreglarlo cuando se rompe y de saber qué puede hacer sin que se lo pidas.

Caso real: el agente que borró la base de datos. En julio de 2025, Jason Lemkin, fundador de SaaStr (una comunidad muy conocida de empresas de software), hizo un experimento público de vibe coding con el agente de Replit. En el noveno día, el agente borró la base de datos real del proyecto, con registros de más de 1.200 ejecutivos y cerca de 1.200 empresas, pese a que Lemkin le había indicado que no hiciera cambios. Además, le dijo que no era posible recuperar los datos. Resultó que sí se podía, y se restauraron. El CEO de Replit, Amjad Masad, pidió disculpas públicamente, lo calificó de inaceptable y en pocos días la empresa separó automáticamente las bases de datos de prueba de las reales.

La lección no es "no uses agentes". Es: no le des a la IA acceso a nada que no puedas perder, tené copias de lo importante, separá lo que es prueba de lo que es real y no confíes en lo que la IA dice sobre lo que hizo sin verificarlo. Cada tanto, pedile que te explique en lenguaje simple qué construyó y qué hace cada parte. No hace falta entender cada línea. Sí hace falta entender el mapa.

Dependencia de la herramienta

Si tu producto vive entero dentro de una plataforma, dependés de sus precios, sus cambios y su supervivencia.

Caso real: Windsurf. Windsurf era uno de los editores de código con IA más usados. En julio de 2025, su venta a OpenAI, por unos 3.000 millones de dólares, se cayó a último momento. En cuestión de días, Google contrató a su CEO y a parte del equipo mediante un acuerdo de licencia, y la empresa Cognition compró lo que quedaba. La herramienta siguió funcionando, pero sus usuarios pasaron a depender de otra empresa, con otra estrategia.

Para reducir el riesgo: preferí herramientas que te dejen llevarte el código (por ejemplo, sincronizando con GitHub), tené tus datos en un lugar exportable y usá tu propio dominio desde el principio. Si cambiás de herramienta, cambiás adónde apunta el dominio y tus usuarios no se enteran.

Costos

La mayoría de estas herramientas tiene un plan gratuito limitado y planes pagos por uso: créditos, mensajes o tiempo de cómputo. Cada pedido consume. Cuando la IA se traba y vos insistís veinte veces, consumís veinte veces. Y si tu producto usa IA adentro, cada uso le cuesta algo a tu cuenta con el proveedor. Karpathy terminó agregando pagos a MenuGen: los usuarios compran créditos y él cuenta que les cobra con un margen del diez por ciento, porque cada imagen generada se la cobran a él los servicios de IA que usa.

Tres precauciones: fijá un presupuesto mensual y revisá el consumo cada dos o tres días, configurá límites y alertas de gasto donde se pueda, y si te trabás, pará antes de quemar créditos.

3.8 Publicar: dominio, hosting y analítica mínima

Un MVP que solo funciona en tu computadora no es un MVP. El objetivo es una URL que puedas mandar por WhatsApp y que funcione en el teléfono de cualquiera.

Hosting

El hosting mantiene tu aplicación encendida en internet. Si usaste un constructor con IA, casi seguro ya lo resuelve: hay un botón de publicar y te da una dirección del tipo tu-proyecto.herramienta.app. Para un MVP alcanza y sobra. Si trabajaste con código, las opciones más usadas para proyectos chicos son Vercel, Netlify y Cloudflare Pages, que tienen planes gratuitos y publican automáticamente cada cambio que guardás en GitHub.

Dominio

No es obligatorio esta semana, pero da confianza y te independiza de la herramienta.

• .com.ar o .ar: se registran en NIC Argentina (nic.ar). Necesitás CUIT o CUIL y clave fiscal de ARCA, y el trámite se hace online por Trámites a Distancia. Se renueva cada año.
• .com y otros: en registradores internacionales, como Cloudflare, Namecheap o Porkbun, o desde el mismo hosting.

Después hay que "apuntarlo" al hosting, cargando unos registros que te indica el hosting. Es el tipo de configuración que Karpathy describió como penosa. Si te trabás, pegale a una IA exactamente lo que ves en pantalla, y tené paciencia: los cambios pueden tardar unas horas en verse.

Analítica mínima

Con tres usuarios, lo más importante vas a aprenderlo mirándolos. Pero conviene medir algo desde el primer día, porque en el módulo 6 vas a trabajar con métricas. Lo mínimo: cuántas personas entran, cuántas hacen la acción central y si vuelven.

Opciones: Google Analytics (gratuita y muy completa, a veces demasiado), Plausible o Umami (más simples y respetuosas de la privacidad), PostHog (mide acciones específicas y graba sesiones) o la analítica de tu hosting. Para la acción central, muchas veces alcanza con contar las filas de tu base de datos o planilla. Si grabás sesiones, avisalo en tu página.

Antes de compartir la URL

• Abre en el celular y en la computadora.
• El recorrido completo funciona, con datos reales y con datos raros.
• Un texto explica qué es, para quién y qué hacer.
• Hay una forma de contactarte si algo falla.
• Dice qué datos guardás y para qué.
• Hiciste la revisión de seguridad.
• La analítica mínima funciona.

3.9 Tus primeros tres usuarios y el registro de aprendizaje

Publicar no es el final de la semana. Es la mitad. Solo aprendés cuando alguien lo usa.

Por qué tres, y quiénes

Tres es poco a propósito. No buscás estadísticas: buscás ver con tus propios ojos cómo alguien real se enfrenta a tu producto. Los tres tienen que tener el problema; idealmente, salen de tus entrevistas o de la lista de tu landing del módulo 2. No valen tu pareja ni un amigo que no tiene el problema: lo van a usar para darte el gusto.

Cómo hacer la sesión

Lo ideal es verlos usarlo, en persona o por videollamada con pantalla compartida:

1. Dale una tarea, no un recorrido. "Imaginate que te pasó [el problema]. Usá esto para resolverlo". Y callate.
2. Pedile que piense en voz alta: qué ve, qué busca, qué espera que pase.
3. No ayudes. Cada vez que quieras intervenir, anotalo: ahí falla el producto. Solo ayudá si se traba del todo.
4. Al final, preguntá por el pasado, no por el futuro. Como viste en el módulo 2, "¿lo usarías?" no sirve. Mejor: "¿Cómo lo resolviste la última vez? ¿Esto hubiera cambiado algo?". Y: "¿Querés seguir usándolo esta semana?".
5. Si dice que sí, fijate en unos días si volvió. Volver es la señal más fuerte que vas a tener en esta etapa.

El registro de aprendizaje

Por cada usuario, escribí una ficha el mismo día:

Al final de los tres, un resumen: ¿qué respondió tu MVP sobre la pregunta de la sección 3.1? ¿Qué se repitió? ¿Qué cambiás? Este registro es la parte más importante del entregable: en la revisión de corte del módulo 4 vas a necesitar evidencia, no sensaciones.

Un plan para la semana

Construir ocupa tres días, no siete. Si al final del día 4 no publicaste, recortá y publicá igual. Un MVP publicado con una sola historia funcionando vale más que uno perfecto en tu computadora.

3.10 La IA como socia en esta etapa

En este módulo la IA no es solo una ayuda: es la herramienta con la que construís. Por eso conviene tener todavía más claro para qué sirve y para qué no.

Para qué sirve

• Construir: pantallas, formularios, bases de datos, textos.
• Pensar la especificación: detectar huecos y partir funcionalidades grandes en historias chicas.
• Recortar: es muy buena encontrando partes que se pueden hacer a mano.
• Explicar qué construyó, qué hace cada parte, qué significa un error.
• Revisar seguridad, datos personales y casos raros.
• Destrabarte en la configuración de dominio, hosting y claves.

Para qué no sirve

• No decide qué construir. Si le pedís "una app para [un rubro]", te construye algo genérico. Qué problema y qué funcionalidad sale de tus entrevistas.
• No reemplaza a tus usuarios. Su opinión sobre tu producto no es evidencia.
• No garantiza que algo funcione ni que sea seguro. Dice "listo" aunque no lo esté.
• No se hace responsable. Si se filtran datos de tus usuarios, el responsable sos vos.

La regla de este módulo: la IA construye, vos decidís y verificás.

Algunas instrucciones útiles

Esta es mi hipótesis y lo que aprendí en mis entrevistas: [pegá tu hipótesis y un resumen]. Quiero construir un MVP esta semana. Proponeme tres versiones posibles, de la más chica a la más grande, y para cada una decime qué pregunta respondería, qué parte podría hacer a mano y cuánto trabajo llevaría. Recomendame una y explicame por qué.

Leé esta especificación: [pegá tu especificación]. Todavía no construyas nada. Decime qué pantallas y datos vas a necesitar, qué partes son ambiguas y qué dudas tenés. Después escribime las historias de usuario con criterios de aceptación, de la más importante a la menos.

Antes de publicar, hacé una revisión de seguridad de esta aplicación. Revisá especialmente si un usuario puede ver o modificar datos de otro, si hay datos accesibles sin iniciar sesión, si hay claves secretas expuestas en el código que ve el navegador y si guardo datos personales que no necesito. Explicame cada problema en lenguaje simple y cómo arreglarlo, pero no cambies nada hasta que te lo confirme.

Explicame, como a alguien que no programa, cómo está armada esta aplicación: qué partes tiene, dónde se guardan los datos, qué servicios externos usa y qué pasaría si uno deja de funcionar.

Ejercicio de la semana

La planificación te va a llevar entre dos y tres horas. La construcción, las sesiones y el registro los repartís en la semana, siguiendo el plan de la sección 3.9. Todo por escrito, sobre el problema que elegiste en el módulo 1.

Paso 1. Escribí la pregunta de tu MVP. Releé tu hipótesis y tus notas de entrevistas. En una oración: qué necesitás aprender que todavía no sabés.

Paso 2. Elegí el tipo de MVP. Mago de Oz, concierge, landing o manual (o una combinación). Justificá en dos líneas por qué es la forma más barata de responder tu pregunta.

Paso 3. Definí la única funcionalidad y el recorrido. El momento exacto en que duele, qué tiene que pasar para que deje de doler y el recorrido en cinco pasos o menos. Armá tu lista de lo que no vas a construir.

Paso 4. Escribí la especificación y las historias. Con el formato de la sección 3.6: entre tres y seis historias, con criterios de aceptación, ordenadas.

Paso 5. Construí y publicá. Una herramienta de la sección 3.4, una historia por vez, probando cada una. Antes de publicar, revisión de seguridad y lista de la sección 3.8.

Paso 6. Hacé tres sesiones con usuarios reales. Personas que tengan el problema, con la dinámica de la sección 3.9.

Paso 7. Completá el registro. Una ficha por usuario, el mismo día, y el resumen final: qué respondió tu MVP y qué vas a cambiar.

Entregable

Al final de esta semana tenés que tener:

• Tu MVP publicado, con una URL que cualquiera puede abrir
• Tres usuarios reales que lo probaron
• Un registro de qué aprendiste de cada uno

Sumá al documento del curso la pregunta de tu MVP, tu especificación y tus historias. Los vas a necesitar en la revisión de corte del módulo 4.

Para profundizar

• Charla de la semana. Andrej Karpathy, "Software Is Changing (Again)" ("El software está cambiando, otra vez"), YC AI Startup School, junio de 2025. Unos 40 minutos, en inglés, con subtítulos traducidos automáticamente. Prestá atención a la autonomía parcial, la distancia entre demo y producto, y su experiencia con MenuGen.
• Andrej Karpathy, "Vibe coding MenuGen" (2025). El relato completo de construir y publicar una app con vibe coding, con todo lo que salió mal. En inglés. karpathy.bearblog.dev/vibe-coding-menugen
• Eric Ries, The Lean Startup (2011). En español, El método Lean Startup. Los capítulos sobre experimentos y MVP desarrollan Zappos y Food on the Table.
• Joel Gascoigne, "Idea to Paying Customers in 7 Weeks: How We Did It". El fundador de Buffer cuenta su MVP de dos páginas. En inglés. buffer.com/resources/idea-to-paying-customers-in-7-weeks-how-we-did-it

Glosario del módulo

• MVP (producto mínimo viable): según Eric Ries, la versión de un producto que permite obtener el mayor aprendizaje validado sobre los clientes con el menor esfuerzo.
• Mago de Oz: MVP que parece automático, pero donde una persona hace el trabajo a mano detrás.
• Concierge: MVP donde le das el servicio a mano a cada cliente, y el cliente lo sabe.
• Landing: página que describe un producto y mide si la gente hace algo concreto.
• Vibe coding: construir software pidiéndoselo a una IA en lenguaje natural, aceptando lo que genera sin revisar el código. Término de Andrej Karpathy (febrero de 2025).
• Ingeniería con agentes (agentic engineering): construir dirigiendo agentes de IA, pero revisando y haciéndose responsable del resultado.
• Especificación: documento corto que describe qué vas a construir, para quién y qué no vas a hacer.
• Historia de usuario: descripción de una funcionalidad desde el punto de vista de quien la usa ("como..., quiero..., para...").
• Criterios de aceptación: condiciones concretas para considerar terminada una historia.
• Hosting: servicio que mantiene tu aplicación funcionando en internet.
• Dominio: la dirección propia de tu sitio.
• Registro de aprendizaje: la ficha que escribís por cada usuario con lo que hizo, dónde se trabó y qué aprendiste.

En el próximo módulo

Tenés un problema validado, un producto publicado y el registro de tus primeros usuarios. En el módulo 4 vas a responder la pregunta que define si esto es un negocio: quién paga, cuánto y por qué. Y vas a hacer tu primera revisión de corte: con la evidencia de estas tres semanas, decidir si seguís, si cambiás de rumbo o si soltás este problema.