Cómo escribir el brief de una aplicación: el brief perfecto no existe, empieza con un borrador

La página en blanco del brief bloquea más proyectos que el presupuesto. Un borrador desordenado de veinte minutos basta para empezar, siempre que alguien te haga después las preguntas que no habías visto y un documento limpio vuelva a tus manos para aprobarlo.

Para escribir el brief de una aplicación, empieza por el borrador más desordenado que puedas tolerar: el problema, quién la usa y qué te hace perder tiempo. En Reddit (r/vibecoding, junio de 2026), una persona que impulsa un proyecto pone nombre al bloqueo: «mi punto débil es que no sé escribir ese diseño inicial».

Qué bloquea ante la página en blanco

Tres cosas detienen a un responsable cuando va a escribir. No conoce las palabras del sector y teme parecer un aficionado; dedicamos un artículo entero a ese falso problema: es la herramienta la que debe traducir. No sabe en qué nivel de detalle detenerse, así que escribe tres líneas o cuarenta páginas. Y espera haberlo decidido todo antes de escribir, cuando la mitad de las decisiones solo se ven al ponerlas por escrito.

El borrador desordenado, en veinte minutos

Toma una hoja y escribe sin releer. El problema en una frase, con un ejemplo fechado de la semana pasada. Las personas que usarán la herramienta, con su trabajo real. Tres cosas que haces a mano y te cuestan tiempo. Una cosa que el software nunca deberá hacer. Qué ocurre cuando algo sale mal: un presupuesto rechazado, un cliente que cancela, un pedido entregado tarde. Ese borrador contiene contradicciones y huecos. Se puede usar, y eso es todo lo que se le pide.

Lo que una buena pregunta le hace a un borrador

El paso del desorden a una versión limpia depende de las preguntas. En Maestro, Margaux inicia la definición del proyecto e interroga tu borrador: quién puede modificar un presupuesto ya enviado, qué pasa con un pedido cuando el cliente cambia de idea después de prepararlo, cuántas personas trabajan a la vez en la misma ficha. Esas preguntas no buscan pillarte; hacen aparecer las decisiones que tomas cada día sin haberlas formulado. Un equipo de agentes que pregunta vale más que uno que adivina, y mostramos qué adivina una IA cuando nadie le ha pedido nada.

La versión limpia vuelve a ti para aprobarla

Margaux te propone después un brief redactado, en francés, que lees en quince minutos. Corriges lo que está mal, añades lo que falta y dices «Me parece bien». Entonces Victor escribe el documento de requisitos, el documento que dice qué debe hacer el producto, y pasa por la misma puerta de aprobación. Antes no se construye nada. Este mecanismo invierte el orden habitual: no escribes el documento, lo corriges, un ejercicio que cualquier responsable sabe hacer. Si prefieres llevar tú el lápiz, el método de una hora cronometrada sigue siendo válido y da mejor resultado cuando ya conoces tu tema al detalle.

Lo que un borrador desordenado no resolverá

Conviene marcar un límite. Cuando varias personas de tu empresa tienen ideas diferentes del producto, ningún brief las pondrá de acuerdo por sí solo: todas asentirán ante el mismo documento pensando en cosas distintas, y el desacuerdo reaparecerá en la entrega. Le dedicamos un artículo: un documento validado no es un acuerdo. En ese caso, una persona facilitando la conversación alrededor de una mesa vale más que una herramienta, y una agencia que vende un taller de definición del proyecto se gana lo que cobra.

El borrador de esta noche

Abre un cuaderno y date veinte minutos, con el cronómetro en marcha: problema, personas, tres pérdidas de tiempo, una prohibición y un escenario que sale mal. No busques ni estructura ni vocabulario. Mañana entrega ese borrador a alguien cuyo oficio sea hacer preguntas, un consultor, un proveedor o un equipo de agentes, y júzgalo por las preguntas que te haga antes de la primera línea de código. Un interlocutor que empiece a construir sin hacer ninguna te devolverá un producto parecido a tu borrador, con tachones incluidos.