La mayoría de los proyectos de app que salen mal no se rompen durante el desarrollo. Se rompen en el brief. Si pides presupuesto a tres agencias con una idea vaga, recibirás tres cifras imposibles de comparar y elegirás a ciegas. Saber escribir un brief para tu app es la habilidad menos glamurosa y más rentable de todo el proceso. Aquí tienes los pasos exactos, los errores que ven las agencias cada semana, y una plantilla que puedes copiar hoy mismo.
Qué es un brief de app y por qué lo necesitas
Un brief de app es un documento corto, de dos a cuatro páginas, que explica qué quieres construir, para quién, con qué presupuesto y en qué plazo. No es una especificación técnica ni un documento de requisitos de 40 páginas. Su único trabajo es que cualquier agencia española lo lea y te devuelva un presupuesto realista sin tener que adivinar.
Sin brief, cada agencia rellena los huecos con suposiciones distintas. Una asume iOS y Android, otra asume solo iOS. Una incluye panel de admin, otra no. Cuando recibes las propuestas, no estás comparando manzanas con manzanas, estás comparando manzanas con bicicletas. El brief elimina esa ambigüedad antes de que cueste dinero.
Antes de empezar: lo que necesitas tener decidido
No puedes escribir un buen brief si todavía no has tomado ciertas decisiones. Antes de abrir el documento, ten claro lo siguiente:
- El problema concreto que resuelves. No “una app de gestión”, sino “los dueños de gimnasios pierden 4 horas a la semana cuadrando reservas en papel”.
- Quién es el usuario. Edad, contexto, nivel técnico. Una app para fisioterapeutas de 55 años no se diseña igual que una para repartidores de 25.
- Tu rango de presupuesto. Aunque sea aproximado. Si no sabes por dónde anda el mercado, lee primero nuestra guía sobre cuánto cuesta crear una app en España para no pedir un Ferrari con presupuesto de Seat.
- Tu fecha límite real. No “lo antes posible”, sino una fecha con motivo: una feria, una ronda de inversión, una temporada comercial.
Si te falta alguno de estos cuatro, dedica una tarde a resolverlo antes de escribir nada. El brief será diez veces mejor.
Paso 1: define el problema, no la solución
El error más común al escribir un brief para tu app es empezar describiendo pantallas. “Quiero una pantalla de inicio con un menú lateral, un botón rojo arriba a la derecha y un calendario”. Eso le ata las manos a la agencia y, peor aún, esconde el problema real.
Empieza siempre por el problema. Una agencia que entiende qué intentas resolver puede proponerte soluciones que no se te habían ocurrido, y a menudo más baratas. Escribe dos o tres frases sobre el dolor concreto que vives tú o tus clientes, con números si los tienes. “Gestionamos 200 reservas semanales por WhatsApp y se nos cuela un error de doble reserva cada semana” dice más que cinco páginas de wireframes.
Después del problema, describe el resultado que buscas, no el mecanismo. “Quiero que el cliente reserve y pague sin que intervenga mi recepcionista” es un resultado. La agencia decidirá si eso se resuelve con un calendario, una pasarela de pago o ambos.
Un buen truco es escribir el problema en formato “antes y después”. Antes: el cliente llama por teléfono, mi recepcionista apunta la cita en una libreta y a veces se duplica. Después: el cliente reserva solo, paga la señal y recibe un recordatorio automático. Ese contraste de dos líneas le dice a la agencia más sobre tu app que un documento entero de especificaciones, porque captura el valor real que persigues, no la decoración.
Paso 2: describe el alcance y las funcionalidades
Aquí es donde el brief se vuelve concreto. Lista las funcionalidades en tres grupos para que la agencia entienda qué es imprescindible y qué puede esperar:
- Imprescindible (la v1 no existe sin esto). Login, reserva, pago. Lo mínimo para que la app tenga sentido.
- Importante pero aplazable. Notificaciones push, historial de reservas, valoraciones.
- Deseable a futuro. Programa de fidelización, integración con tu ERP, chat con soporte.
Esta priorización es oro puro para presupuestar. Permite a la agencia cotizarte un MVP defendible y enseñarte cuánto sube cada bloque adicional. También te protege a ti: cuando el presupuesto aprieta, sabes exactamente qué recortar sin romper el producto.
Para cada funcionalidad imprescindible, indica si necesitas integraciones externas. Pagos con Stripe, Redsys o Bizum, mapas, OCR, facturación. Cada integración tiene un coste real y un riesgo distinto, y mencionarlas en el brief evita sorpresas de cinco cifras a mitad de proyecto. Si no sabes qué integración necesitas, descríbela en lenguaje normal: “el cliente paga con tarjeta dentro de la app” basta para que la agencia proponga la pasarela adecuada.
Indica también las plataformas. iOS, Android, web, o las tres. Esta sola decisión puede duplicar el presupuesto, así que conviene tomarla con criterio y dejarla escrita.
Paso 3: pon presupuesto y plazos sobre la mesa
Muchos fundadores ocultan el presupuesto por miedo a que la agencia “infle hasta el tope”. Es un error. Sin una cifra de referencia, la agencia no sabe si diseñarte un MVP de 25.000 € o un producto de 120.000 €, y acabará proponiéndote algo que no encaja con tu realidad.
Da un rango honesto. “Tenemos entre 30.000 € y 45.000 € para la v1” orienta a la agencia para proponerte el mejor producto posible dentro de ese marco. Una buena agencia te dirá si tu idea cabe en ese rango o si hay que recortar alcance, y eso es justo la conversación que quieres tener antes de firmar, no después.
Pongamos un ejemplo concreto. Imagina que tienes 35.000 € y quieres lanzar una app de reservas para tu cadena de tres peluquerías antes de septiembre. Un brief que diga “presupuesto 30.000 a 40.000 €, lanzamiento en septiembre por el arranque de temporada, imprescindible reserva y pago, aplazable el programa de puntos” le permite a la agencia diseñarte una v1 sensata y reservar el programa de fidelización para una segunda fase. Sin esos datos, recibirías propuestas que van de los 22.000 € a los 70.000 € y ninguna encajaría con tu calendario.
Con los plazos, sé realista y explica el porqué. Una fecha con motivo (“queremos lanzar antes de la campaña de Navidad”) es accionable. Una fecha sin motivo (“para ya”) solo genera presión y atajos. Recuerda que una app de gama media en España tarda entre 12 y 20 semanas, así que si tu fecha está a seis semanas, el brief debe reflejar que habrá que reducir alcance.
Paso 4: los errores que arruinan un brief
Después de leer cientos de briefs, estos son los fallos que vemos una y otra vez:
- El brief-novela. Cuarenta páginas con cada detalle de UI especificado. Nadie lo lee entero y, encima, ata a la agencia a tus suposiciones. Dos a cuatro páginas bastan.
- El brief sin presupuesto. Ya lo hemos dicho, pero se repite tanto que merece insistir. Oculta el presupuesto y recibirás propuestas inservibles.
- Confundir features con objetivos. “Quiero gamificación” no es un objetivo. “Quiero que el usuario vuelva tres veces por semana” sí lo es. Deja que la agencia proponga el mecanismo.
- No decir quién decide. Si tres socios tienen que aprobar cada cambio, dilo. La agencia planificará el proyecto de otra forma para evitar bloqueos.
- Olvidar el después. El brief debe mencionar quién mantendrá la app tras el lanzamiento. El mantenimiento ronda el 8% al 15% del coste de desarrollo al año, y conviene tenerlo en el radar desde el principio.
Plantilla de brief para tu agencia de apps
Copia esta estructura y rellénala. Con esto tienes un brief que cualquier agencia española entiende a la primera:
# Brief: [nombre del proyecto]
## 1. El problema
[2-3 frases sobre el dolor concreto, con números si los hay]
## 2. El usuario
[Quién lo usará: edad, contexto, nivel técnico]
## 3. El resultado que buscamos
[Qué queremos que el usuario consiga, no cómo]
## 4. Funcionalidades
- Imprescindible: [lista]
- Importante pero aplazable: [lista]
- Deseable a futuro: [lista]
## 5. Integraciones y plataformas
- Plataformas: [iOS, Android, web]
- Integraciones externas: [pagos, mapas, etc.]
## 6. Presupuesto
[Rango honesto en euros para la v1]
## 7. Plazo
[Fecha con motivo]
## 8. Quién decide
[Nombres y rol de quienes aprueban]
## 9. Qué pasa después del lanzamiento
[Quién mantiene la app, expectativa de soporte]
Una página por sección no, una o dos frases por sección sí. La brevedad es una virtud aquí.
Cómo saber que tu brief está listo
Tu brief está terminado cuando pasa una prueba sencilla: dáselo a leer a alguien que no conozca tu proyecto y pregúntale qué crees que construye la app y para quién. Si te lo describe correctamente en treinta segundos, está listo. Si duda o se inventa cosas, hay huecos que rellenar.
La segunda prueba es de presupuesto. Si tres agencias leen tu brief y te devuelven cifras dentro de un rango razonable entre ellas, el brief funciona. Si las cifras se disparan unas de otras, casi siempre es porque el alcance no estaba claro, no porque las agencias sean deshonestas.
Qué hacer después
Un brief sólido te ahorra semanas de idas y venidas y, lo más importante, te deja comparar agencias por lo que de verdad importa: cómo entienden tu problema, no quién rellena más páginas. Si ya tienes tu brief listo y quieres un presupuesto honesto sin compromiso, cuéntanos tu proyecto y te decimos en qué rango cae tu idea y por qué.
Y si todavía estás puliendo las cifras, repasa antes nuestra guía sobre cuánto cuesta crear una app en España para entrar a la conversación con expectativas realistas.
.webp)
.webp)


