De idea a app en un día: el flujo completo, paso a paso

Paso 1: define el problema antes de pedir nada

El error más común es empezar por la app. Antes de escribir un prompt, responde tres preguntas: quién es el usuario, cómo resuelve hoy esa tarea y qué datos necesita la app, y dónde viven esos datos ahora. Son preguntas simples, pero la respuesta decide la estructura del producto.

Addy Osmani, en su libro “Beyond Vibe Coding”, contrasta el vibe coding exploratorio (describir lo que quieres y dejar que el modelo rellene los huecos) con un trabajo guiado por la intención, donde fijas objetivos y restricciones claros y revisas con ojo crítico lo que genera la IA (O’Reilly, Beyond Vibe Coding). Fijar objetivos y restricciones empieza por escribirlos. Para la idea de un día, basta con una página: usuario, tarea, tres reglas y qué significa que funcione. Un formato útil está en cómo escribir un PRD que un agente entienda.

Paso 2: genera en bloques pequeños

Pedir la app completa en un prompt produce algo difícil de revisar. Conviene dividir el trabajo en bloques: primero la pantalla principal con datos de prueba, luego el guardado, después el acceso de usuarios. Cada bloque se prueba antes de pasar al siguiente. Si algo se rompe, sabes qué lo rompió. Es la misma lógica de iterar por prompts sin perder el control.

Paso 3: revisa datos y accesos

Este es el paso que más se salta cuando todo va rápido. En una app que habla con la base de datos desde el navegador, la base debe decidir quién ve qué. La documentación de Supabase lo explica con su mecanismo de Row Level Security: las políticas actúan como una cláusula de filtro en cada consulta. Sin esas reglas, una tabla expuesta puede quedar legible o escribible por cualquier rol con permisos, y en proyectos con permisos por defecto las tablas nuevas en el esquema público pueden quedar abiertas a anon y authenticated (Supabase, Row Level Security). Supabase está cambiando ese valor por defecto para que exponer una tabla a la API sea una decisión explícita (Supabase, Securing your API), pero los proyectos ya creados conservan sus permisos actuales: no lo des por hecho, compruébalo en tu proyecto.

En la práctica, en esta etapa revisa:

• que cada tabla tenga reglas de acceso activas;
• que ningún secreto esté en el código del cliente;
• que dos usuarios distintos vean solo sus datos;
• qué datos personales guarda la app y por cuánto tiempo.

Paso 4: despliega y verifica

Desplegar es publicar la app en una URL accesible desde internet. Las plataformas actuales suelen crear un despliegue de vista previa por cada cambio, y uno de producción que se promueve o se revierte. Vercel, por ejemplo, documenta despliegues de vista previa y de producción desde Git o desde su CLI (Vercel, Deploying to Vercel). También permite promover un despliegue de vista previa a producción y hacer un rollback instantáneo, que reasigna tus dominios a un despliegue anterior sin reconstruirlo (Vercel, Instant Rollback). Si tu plataforma es otra, busca esas dos funciones antes de elegirla.

Antes de promover un cambio a producción, abre la URL de vista previa, prueba el flujo principal con una cuenta real y revisa los registros de errores. Si algo falla, el despliegue anterior debe poder volver a funcionar.

Ejemplo

Ejemplo ilustrativo: un diseñador quiere una app para que su equipo registre devoluciones de prototipos a clientes. Por la mañana define el problema (quién registra, qué campos, qué estados) en una página. Pide la pantalla con datos de prueba y, después, el guardado. Por la tarde, revisa que cada usuario vea solo sus registros y que la clave del servicio no aparezca en el código del navegador. Publica una vista previa, prueba con dos compañeros y la promueve a producción. El flujo cabe en un día porque el alcance es pequeño y las pruebas son concretas.

¿Cuándo no cabe en un día?

Cuando la app guarda datos de clientes, procesa pagos, necesita roles complejos o tiene integraciones con otros sistemas. Esos casos requieren revisión de ingeniería, que puede durar días. Ver cuándo no hacer vibe coding para los criterios. El propio Osmani advierte que el enfoque exploratorio tiene un riesgo serio: puede desviarse rápido del rumbo, y por eso insiste en revisar con criterio lo que genera la IA.

Cómo aplicarlo mañana

1. Escribe la idea en una página con tres campos: usuario, tarea y criterio de éxito. Si no puedes llenar un campo, esa parte se queda fuera del día.
2. Divide el trabajo en tres bloques de una hora cada uno: pantalla con datos de prueba, guardado y acceso. Cierra cada bloque con una prueba que pase o falle.
3. Antes de desplegar, revisa tres cosas: reglas de acceso en la base de datos, secretos fuera del código del navegador y una cuenta de prueba que no sea la tuya.
4. Publica primero una vista previa, pruébala con alguien que no la construyó y solo después promuévela a producción.

Si al final del día tienes una URL que funciona y una lista de lo que falta, el experimento salió bien.

Antes de cerrar el día, escribe en una página qué sigue: qué falta, quién lo revisará y qué datos reales necesita la app. Esa página es la diferencia entre un prototipo que se queda abandonado y uno que se convierte en producto con dueño.

Errores comunes

• Empezar a generar sin definir el problema ni los datos.
• Pedir la app completa en un solo prompt.
• Dejar las reglas de acceso de la base de datos para después.
• Publicar directamente a producción sin vista previa.
• Confundir “se despliega” con “está lista para usuarios”.
• No tener forma de volver a la versión anterior si algo falla.

Fuentes

• Addy Osmani, “Beyond Vibe Coding” (O’Reilly): https://www.oreilly.com/library/view/beyond-vibe-coding/9798341634749/
• Supabase, “Row Level Security”: https://supabase.com/docs/guides/database/postgres/row-level-security
• Supabase, “Securing your API”: https://supabase.com/docs/guides/api/securing-your-api
• Vercel, “Deploying to Vercel”: https://vercel.com/docs/deployments
• Vercel, “Instant Rollback”: https://vercel.com/docs/instant-rollback