GuíasCómo hacer

Cómo escribir el prompt de una app

El prompt de una app no es una redacción. Es un pedido, y un buen pedido responde a cuatro preguntas antes de describir ninguna pantalla.

Datos de 6 de septiembre de 2026

Las cuatro cosas que no pueden faltar

  1. Quién la usa. Una persona concreta, no "los usuarios". Cambia todo saber si quien abre es el cliente, el empleado o el dueño.
  2. Qué hace ahí. Un verbo por vez: pedir, reservar, registrar, aprobar, consultar.
  3. Qué queda guardado. Es lo que después se convierte en lista, filtro, búsqueda e informe. Es la parte que más se olvida y la más cara de arreglar.
  4. Quién ve qué. Basta una frase, y evita el defecto más caro: un cliente viendo el pedido de otro.

Una plantilla corta que funciona

Una app para que [quién] pueda [qué hace]. Cada [registro] guarda [campos]. [Quién] ve solo lo suyo; [quién] lo ve todo. Cuando [pasa algo], la app [avisa a alguien / cambia el estado].

Cuatro líneas cubren más que una página de deseos sueltos. El resto se resuelve mejor mirando la pantalla terminada.

Qué dejar fuera del primer pedido

  • tecnología, si no tienes un motivo concreto;
  • colores y tipografía, salvo que la marca ya exista. Lo visual es la parte fácil de cambiar después;
  • funciones de la versión 3. Informes avanzados, panel de métricas e integraciones entran cuando la versión 1 tenga gente usándola;
  • login, si todavía no hay a quién iniciar sesión.

El segundo prompt importa más que el primero

El primer pedido genera la app. Los siguientes son los que la dejan bien, y tienen otra forma: en vez de describirlo todo, señalan un punto.

Un buen pedido de corrección tiene tres partes:

  • dónde: la pantalla o el botón;
  • qué pasa hoy;
  • qué debería pasar.

"En la lista de pedidos, el filtro de fecha no cambia nada cuando elijo el mes; debería mostrar solo los pedidos de ese mes." Ese pedido cambia poquísimo. "Mejora la pantalla de pedidos" invita a reescribir lo que ya estaba bien.

Cuando el problema es de maquetación, la captura vale más que el párrafo.

Errores que aparecen cada semana

  • pedirlo todo de una vez. La app nace grande, mal en varios sitios, y cuesta saber qué corrección rompió qué;
  • describir la solución en vez del problema. "Pon un campo oculto que guarde el estado" le quita a la IA la posibilidad de acertar mejor;
  • cambiar de tema a mitad. Un pedido, un tema;
  • no decir la regla de permiso, y descubrirlo delante de un cliente.

El resumen

  • quién la usa, qué hace, qué queda guardado, quién ve qué;
  • cuatro líneas valen más que una página;
  • deja tecnología y estética para después;
  • corrección con dónde, qué pasa y qué debería pasar;
  • un pedido, un tema, y captura cuando sea maquetación.

Preguntas frecuentes

¿Un prompt largo funciona mejor?
No. Demasiado largo diluye lo que importa y deja que la IA elija sola qué atender. El párrafo corto con quién, qué y qué queda guardado funciona mejor que la página entera.
¿Hay que pedir la tecnología en el prompt?
No, y pedirla sin motivo suele empeorar. Describe comportamiento; la elección técnica es de la plataforma, que ya tiene un conjunto que encaja.
¿Pongo los colores y la tipografía en el primer pedido?
Solo si la marca ya existe. Lo visual es lo más fácil de cambiar después, y gastar en ello el primer pedido quita sitio a lo difícil de acertar.
¿Cómo pido una corrección sin romper el resto?
Nombra la pantalla, qué pasa hoy y qué debería pasar. Un pedido con esos tres puntos cambia poco código; uno genérico invita a reescribir.
¿Vale la pena pegar una captura en el pedido?
Mucho, y es la forma más rápida de resolver un problema de maquetación. La imagen dice en un segundo lo que un párrafo intenta describir.
Empieza a construir gratis
Lee también
Cómo crear una app con IACómo crear una app desde ceroQué modelo de IA usar para generar una app