He visto a tres personas distintas gestionar mal la misma pantalla de treinta segundos —la tarjeta del plan que aparece entre tu prompt y la construcción— y cada una lo pagó de una forma diferente. Una lo pagó con una reconstrucción. Otra, con tiempo de escritura desperdiciado. Otra, con un producto que no podía hacer lo que realmente necesitaba. La tarjeta del plan es el momento más barato de todo el proceso para cambiar de opinión, y precisamente por eso es tan fácil pasarla por alto.
Error uno: aprobarla sin mirar
Este es el más habitual. El esquema parece correcto, pulsas aprobar y sigues adelante; yo hice esto durante semanas antes de que me pasara factura. La construcción que finalmente acabó con ese hábito volvió con un checkout de Stripe conectado a un sitio estático que no tenía dónde guardar el estado de cuenta que Stripe necesitaba. El plan decía tipo de producto: sitio estático en texto claro, justo ahí en la tarjeta, y lo pasé por alto porque la lista de páginas parecía correcta y tenía prisa.
El desastre resultante de este error siempre tiene la misma forma: todo lo que viene después del plan es correcto dado el plan, así que el fallo no aparece como un error, aparece como una construcción funcional que es estructuralmente incorrecta. Nadie lo detecta porque nada está roto: un sitio estático con un botón de pago simplemente hace lo incorrecto en silencio, o falla justo en el momento en que un usuario real intenta "pagar". Te enteras en la revisión, que es el lugar más caro para enterarte.
Error dos: sobreespecificar para evitar una segunda ronda
El error opuesto parece más responsable, pero no lo es. Algunas personas, tras sufrir el error uno, sobrecorrigen y acaban escribiendo un párrafo de requisitos precisos en la etapa del plan: texto exacto, preferencias de espaciado, qué funciones deben o no deben existir, redactado como un documento de especificaciones. Yo también he hecho esto, por una vaga ansiedad de que saltarse el detalle ahora significa "desperdiciar" una ronda de construcción más adelante.
Es contraproducente, y esta es la razón: el plan se va a revisar de nuevo en cuanto veas las páginas reales, sin importar cuán cuidadoso hayas sido la primera vez. Y cuando se revise, no obtienes un diff de lo que cambió: recibes una tarjeta nueva que ya incorpora tu edición, punto, sin notas de cambios. Así que la precisión que escribiste en la primera ronda no sobrevive intacta a la segunda de todos modos; vas a releerlo todo de nuevo en cualquier caso. Dos o tres rondas de "no, así" te llevan a un mejor resultado, más rápido en tiempo real, que un brief exhaustivo, aunque escribir el brief se sienta más eficiente mientras lo haces.
Las ediciones en lenguaje sencillo que realmente funcionan son cortas:
- "Quita el blog, añade una página de precios" — cambia la lista de páginas sin complicaciones.
- "Hazlo para dos jugadores en lugar de uno" — es más grande de lo que parece. Puede afectar al modelo de datos, que ahora rastrea a dos participantes en lugar de uno, y el plan revisado mostrará esa repercusión en vez de ocultarla.
- "Esto necesita cuentas de usuario" — si el plan actual es un sitio estático, esta es la frase que obliga a plantear directamente la cuestión del tipo de producto.
Error tres: tratar el tipo de producto como un campo secundario
Este es el más caro, y lo es porque todo lo demás en la tarjeta es genuinamente recuperable. Páginas, funciones inferidas, la mayoría de las bifurcaciones de preguntas: todo se puede corregir con una iteración de versión una vez que la construcción esté lista. El tipo de producto no. Hay cuatro categorías:
| Tipo de producto | Qué significa |
|---|---|
| Sitio estático | Sencillo, sin lógica de servidor. |
| Aplicación instalable | Estilo PWA: funciona sin conexión, se puede añadir a la pantalla de inicio, sigue sin lógica de servidor. |
| Compilación basada en framework | Estilo React/Next, con más interactividad en el cliente, pero aún sin backend persistente. |
| Aplicación con backend | El único de los cuatro con una base de datos real y un sistema de cuentas detrás. |
Apruebas un plan de sitio estático, y tres versiones después decides que quieres inicio de sesión: eso no es un salto de versión, es una reconstrucción desde un tipo de producto distinto, y pierdes la continuidad que el historial de versiones te daba en todo lo demás.
La gente se equivoca en esto de dos formas. Primero, no comparan su propio prompt con el campo: si tu prompt incluye "cuentas", "inicio de sesión", "guardar", "panel que se actualiza", "pagos" o "varios usuarios editando lo mismo", y la tarjeta no dice con soporte de servidor, esa es la única edición que vale la pena hacer antes de aprobar, sin excepciones. Segundo, confunden aplicación instalable con construcción con framework, porque ambas se sienten como "una aplicación" en una conversación informal. No son intercambiables: aplicación instalable encaja con una herramienta donde todo el estado vive en el dispositivo del usuario, una calculadora de propinas, un temporizador de entrenamiento. Construcción con framework significa más interactividad y estructura de componentes, pero sigue sin nada que persista en el servidor entre sesiones o dispositivos. Ninguna de las dos es "una aplicación" en el sentido de tener cuentas y datos que te siguen entre dispositivos; solo con soporte de servidor lo es. Y sobredimensionar hacia con soporte de servidor "por si acaso" para un sitio de portafolio o una página de documentación tampoco es la opción segura: reducirlo después es tanta reconstrucción como habría sido ampliarlo.
Lo que queda una vez que dejas de hacer esas tres cosas
Una vez que dejas de pasar por alto la línea del tipo de producto, de escribir una especificación en la etapa del plan y de tratar como negociable el lenguaje de cuentas, datos o pagos en tu propio prompt, lo que queda es una revisión rápida y acotada:
- Lee el tipo de producto.
- Compáralo con tu prompt.
- Revisa por encima la lista de funciones inferidas en busca de algo que rechazarías a simple vista.
Esa lista existe precisamente porque un prompt como "herramienta de reservas para peluquerías" arrastra cosas que no escribiste: vista de calendario, recordatorios por SMS, una lista de clientes; algunas las querías y otras son expansión de alcance que el modelo añadió porque, estadísticamente, esas funciones suelen ir juntas. Elimina lo que no encaje con una frase, aquí, en lugar de después de que esté construido.
Todo lo demás —el texto, el espaciado, qué tono de color de acento, si el botón dice "Empezar" o "Probar gratis"— ni siquiera aparece en la tarjeta, a propósito. Son cosas baratas de ver y corregir en una construcción funcional, así que la tarjeta no desperdicia tu atención en ellas, y tú tampoco deberías. Eso son quizás quince segundos de juicio real dentro de los treinta segundos que se tarda en leerla.
