01 Qué es el vibe coding y dónde falla
Con los agentes de programación actuales puedes describir una aplicación en lenguaje natural y obtener código funcionando en minutos. El problema no es arrancar, sino terminar: sin un plan, cada petición añade algo y rompe otra cosa, el alcance crece y la app nunca llega a publicarse.
La diferencia entre una demo vistosa y un producto que alguien usa está casi siempre en lo que decides antes de abrir la herramienta: qué problema resuelves, qué entra en la primera versión y qué se queda fuera.
-
1
Define
Un documento de requisitos (PRD) corto y concreto.
-
2
Elige herramienta
Según cuánto control técnico necesites.
-
3
Resuelve datos y usuarios
Base de datos, autenticación y, si hace falta, búsqueda semántica.
-
4
Construye la versión mínima
Solo lo imprescindible, probado de principio a fin.
-
5
Publica
Primero en la web; las tiendas de apps, después.
02 Paso 1: el documento de requisitos
Un PRD (Product Requirements Document) es el plano de tu app. No tiene que ser largo, pero sí responder a cuatro preguntas: qué problema resuelves y para quién, qué debe hacer sí o sí la primera versión, qué dejas fuera a propósito y cómo sabrás que funciona. Ese documento es también el mejor contexto que puedes darle después al agente que construya.
Quiero que me ayudes a escribir el documento de requisitos de una app. Antes de redactar nada, hazme preguntas de una en una hasta tener claro: el problema, quién lo sufre, qué hace hoy esa persona para resolverlo, la acción principal de la app y cómo voy a ganar dinero o ahorrar tiempo con ella. Recomienda una respuesta en cada pregunta para que pueda ir rápido.
Cuando termines, entrégame en Markdown:
1. Resumen en un párrafo.
2. Usuario objetivo.
3. Alcance de la versión 1: lista de lo que entra y lista de lo que NO entra.
4. Requisitos funcionales como historias de usuario con criterios de aceptación.
5. Requisitos no funcionales: privacidad, seguridad, rendimiento, accesibilidad.
6. Datos que guarda la app y quién puede verlos.
7. Arquitectura sugerida y por qué.
8. Métricas para saber si funciona.
9. Riesgos y supuestos.
10. Fases: versión mínima, versión 1 y versión 2.03 Paso 2: elige la herramienta según tu nivel
| Tu punto de partida | Tipo de herramienta | Ejemplos | A tener en cuenta |
|---|---|---|---|
| Cero código | Constructores de apps en el navegador | Lovable, Bolt, Replit | Muy rápidos para prototipos; revisa cómo exportar el código y qué cuesta escalar. |
| Algo de código o ganas de aprender | Editores con IA | Cursor, Windsurf | Ves y controlas cada archivo; necesitas un entorno local. |
| Control total y proyectos serios | Agentes de terminal | Claude Code, Codex | Trabajan sobre tu repositorio, ejecutan pruebas y comandos; requieren criterio técnico para revisar. |
No hay una herramienta mejor en abstracto. Un buen camino es prototipar en un constructor visual para validar la idea con usuarios y, si funciona, pasar a un repositorio propio con un agente como Claude Code para tener control, pruebas y mantenimiento.
04 Paso 3: datos, usuarios e IA
Base de datos y autenticación
Servicios como Supabase (PostgreSQL) o Firebase te dan base de datos, inicio de sesión y almacenamiento sin montar servidores. Casi cualquier app real necesita uno.
Búsqueda semántica
Si la app debe buscar por significado en documentos o recordar contexto, necesitas vectores: una base vectorial dedicada como Pinecone o la extensión pgvector en PostgreSQL.
Modelos de IA
Si la app llama a un modelo, hazlo siempre desde el servidor, nunca exponiendo la clave de API en el navegador.
05 Paso 4: construir la versión mínima
Lee PRD.md. Antes de escribir código, propón un plan de trabajo en pasos pequeños que se puedan probar uno a uno, empezando por el flujo principal de punta a punta con datos de prueba. Para cada paso indica qué archivos crearás y cómo comprobaremos que funciona. No implementes nada de la lista «fuera de alcance». Espera mi aprobación del plan.- ✓Pide un cambio cada vez y comprueba el resultado antes del siguiente.
- ✓Usa control de versiones (Git) desde el primer día para poder volver atrás.
- ✓Prueba el flujo principal completo, como lo haría un usuario nuevo, antes de añadir funciones.
- ✓Cuando algo falle, pega el error exacto y pide primero un diagnóstico, no un arreglo a ciegas.
- ✓Guarda en el repositorio un archivo de instrucciones para el agente con las decisiones tomadas.
06 Paso 5: publicar
| Destino | Qué necesitas |
|---|---|
| Web | Una plataforma de despliegue como Vercel o tu hosting habitual, y un dominio. Es la forma más rápida de tener usuarios. |
| App Store (iPhone) | Apple Developer Program, con cuota anual de 99 USD en moneda local, y pasar la revisión de Apple. |
| Google Play (Android) | Cuenta de desarrollador con un pago único de 25 USD, verificación de identidad y revisión de la app. |
Empieza por la web: puedes iterar cada día sin revisiones de tienda. Pasa a las tiendas solo cuando sepas que la gente vuelve a usar la app y necesites notificaciones, acceso a funciones del móvil o presencia en el catálogo.
Preguntas frecuentes
Puedes crear un prototipo funcional, sí. Para algo que maneje datos de clientes o pagos necesitarás aprender lo básico de seguridad o contar con alguien técnico que lo revise.
Porque la IA construye exactamente lo que le pides. Sin un alcance claro, cada mensaje cambia el rumbo y la app nunca se termina.
Si no programas, un constructor en el navegador para validar la idea. Si buscas un producto mantenible, un repositorio propio con un agente como Claude Code.
En la web puedes empezar gratis o por pocos euros al mes. Apple cobra una cuota anual de 99 USD en moneda local y Google Play un pago único de 25 USD.
Sobre el autor
Equipo editorial de appyweb
Marketing, SEO y desarrollo con IA
Especialistas de appyweb en SEO, publicidad, desarrollo web y automatización con IA.